https://rue-a.github.io/L-Systems/ became slightly slower after the new buffer allocator
Categories
(Core :: JavaScript Engine, defect, P2)
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)
46.72 KB,
text/plain
|
Details |
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.
Comment 1•1 month ago
|
||
Set release status flags based on info from the regressing bug 1934856
Comment 2•1 month ago
|
||
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.
Reporter | ||
Comment 3•1 month ago
•
|
||
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?
Reporter | ||
Comment 4•1 month ago
|
||
Reporter | ||
Comment 5•1 month ago
|
||
(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
Comment 6•1 month ago
|
||
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.
Comment 7•1 month ago
|
||
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
Updated•1 month ago
|
Reporter | ||
Comment 8•28 days ago
|
||
Latest profile as many patches have landed subsequently: https://share.firefox.dev/4gV96ti (not much change as expected)
Reporter | ||
Comment 9•27 days ago
|
||
Profile with javascript.options.extra_gc_poisoning=TRUE
https://share.firefox.dev/4jlOU59
Comment 10•24 days ago
|
||
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.
Description
•