JS demo (https://www.fxhash.xyz/generative/23379 ) is much slower in Nightly compared to Chrome
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
People
(Reporter: mayankleoboy1, Unassigned)
References
(Blocks 1 open bug)
Details
Go to https://www.fxhash.xyz/generative/23379 (The specific example/hash would be this: https://gateway.fxhash2.xyz/ipfs/QmRmzG8iTV2yYy2r6EfCrGQwCkVJLMCZnmiRftxtXU24Gm/?fxhash=ooqiQkreHHYb3ijW3PwqF6kj1gw5yTVEzoPzdanGeAnDnNDuCMe)
Nightly: https://share.firefox.dev/3QV8mrS
Chrome: https://share.firefox.dev/3H1Y4le
Updated•2 years ago
|
Reporter | ||
Comment 1•2 years ago
|
||
This is improved a lot now.
Total improvement: 4.4s ->1.0s
First fix (4.4->3.2s) : Bug 1817640 - extract calculation of max dirty value to a helper method EffectiveMaxDirty(), r=pbone
Second fix (3.2->2.2s): Bug 1609478 - Poison memory we want to free before we take the arena lock r=glandium
Third fix (2.2->1.5s): Bug 1827258 part 4 - Add fast paths for optimizing common cases with packed arrays. r=jonco
Comment 2•2 years ago
|
||
That's a great analysis. Thank you!
Reporter | ||
Comment 3•6 months ago
|
||
Nightly: https://share.firefox.dev/46RBSXr (450ms)
Chrome: https://share.firefox.dev/3YPEUt9 (180ms)
I tested on a build from comment #1, and got ~600ms, where I previously got 1.5s. So looks like fxhash updated/fixed some of their code (or the JS libraries).
Comment 4•6 months ago
|
||
(In reply to Mayank Bansal from comment #3)
Nightly: https://share.firefox.dev/46RBSXr (450ms)
A lot of time is spent in memcpy_repmovs
copying elements for array concat
. This is using the fast path added in bug 1827258.
Also some slow malloc
calls for the elements. This would likely benefit from the object slots/elements allocator work.
Reporter | ||
Comment 5•1 month ago
•
|
||
Latest profile: https://share.firefox.dev/4gK13zd (1.1s)
Looks like the allocator work regressed this?!
Edit: Profile of a build from yesterday: https://share.firefox.dev/40ryJMx
So there is some variation, and looks like 1.1s may either a small regression or no change.
Comment 6•1 month ago
|
||
We're now spending a lot longer poisoning memory while freeing on the background thread. I'm not sure how this is possible since the amount of memory freed should be the same but I'll look into it.
Reporter | ||
Comment 7•1 month ago
|
||
Latest profile: https://share.firefox.dev/40ovvYU
Description
•