Open Bug 1811784 Opened 2 years ago Updated 1 month ago

JS demo (https://www.fxhash.xyz/generative/23379) is much slower in Nightly compared to Chrome

Categories

(Core :: JavaScript Engine, task, P3)

task

Tracking

()

People

(Reporter: mayankleoboy1, Unassigned)

References

(Blocks 1 open bug)

Details

Severity: -- → S3
Priority: -- → P3

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

Depends on: 1817640, 1609478, 1827258

That's a great analysis. Thank you!

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).

(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.

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.

Depends on: 1934856

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.

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