Open Bug 1940491 Opened 1 month ago Updated 24 days ago

https://rue-a.github.io/L-Systems/ became slightly slower after the new buffer allocator

Categories

(Core :: JavaScript Engine, defect, P2)

defect

Tracking

()

Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 --- unaffected
firefox134 --- unaffected
firefox135 --- unaffected
firefox136 --- fix-optional

People

(Reporter: mayankleoboy1, Unassigned, NeedInfo)

References

(Blocks 1 open bug, Regression, )

Details

(Keywords: regression)

Attachments

(1 file)

I use mozregression to download and run nightly builds (without installation).

Go to https://rue-a.github.io/L-Systems/
Click on iterate button 7 times. The timings below are for the 7th iteration.

8Jan2025 (with the new buffer allocator): https://share.firefox.dev/3PrTDos (28s)
7Jan2025: https://share.firefox.dev/40aVF0Y (24s)

I am filing this bug more to have a (hopefully easier) testcase to refer to which has some small regression.

Flags: needinfo?(jcoppeard)

Set release status flags based on info from the regressing bug 1934856

The profile shows the build with the buffer allocator waiting on the main thread for nursery sweeping to finish on a background thread. This happens becuase nursery sweeping spends more time poisoning data than for the build that uses jemalloc. This doesn't really make sense as they should be doing the same amount of work here.

When I run this test case locally on macOS I do not see that behaviour. Instead I see the main thread spending more time allocating chunks from the OS for the buffer allocator build, which is a separate issue. I'll try and test on Windows and see if I can reproduce there.

Wild guess: could it be Windows defender scanning memory and causing slowness? (ref bug 1441918 , bug 1823634 )

Partial profile with 8 iteration: https://share.firefox.dev/4h6YvLr

Edit: Profile with Windows Defende Real-time protection disabled. 7 iterations: https://share.firefox.dev/4fLUVoY . Does this seem different from the profile in comment 0?

Attached file about:support

(In reply to Jon Coppeard (:jonco) from comment #2)

The profile shows the build with the buffer allocator waiting on the main thread for nursery sweeping to finish on a background thread. This happens becuase nursery sweeping spends more time poisoning data than for the build that uses jemalloc. This doesn't really make sense as they should be doing the same amount of work here.

Is this phenomenon also occurring on the sp3 perf runs on Win11 machines

I ran this on a Windows machine and reproduced the results you are seeing:

Without buffer allocator: https://share.firefox.dev/4agV2HR
With buffer allocator: https://share.firefox.dev/408Vkfs

Something to watch out for is that Nightly builds do more poisoning than release builds and this does affect performance measurements. However in this case this should affects both builds in the same way.

I tested again after building with --as-milestone=release. In these profiles poisoning doesn't show up at all. It looks like the execution time has decreased from 29 seconds to 24 seconds (but I don't know how variable this is).

Without buffer allocator: https://share.firefox.dev/3WfLO8Z
With buffer allocator: https://share.firefox.dev/40DqLjz

Blocks: sm-js-perf
Severity: -- → S4
Priority: -- → P2

Latest profile as many patches have landed subsequently: https://share.firefox.dev/4gV96ti (not much change as expected)

Profile with javascript.options.extra_gc_poisoning=TRUE
https://share.firefox.dev/4jlOU59

Setting 136 as fix-optional since this was triaged as an S4
Next week is the final week of nightly for Fx136 before it goes to beta.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: