Modified codepen demo spends a lot of time in Map, GCMinor, and Int32ToCStringWithBase
Categories
(Core :: JavaScript Engine, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox136 | --- | fixed |
People
(Reporter: mayankleoboy1, Assigned: iain)
References
(Blocks 2 open bugs, )
Details
Attachments
(3 files)
The original demo has some parameters that you can play with.
Example1: Open the attached testcase
Map-heavy: https://share.firefox.dev/3V69QCR (4.8s)
Not Map heavy: https://share.firefox.dev/3V3HpFQ (12s)
We are faster than Chrome here. But filing this bug in case there is anything obvious we can improve. Else, please feel free to close.
Reporter | ||
Comment 1•3 months ago
|
||
Reporter | ||
Comment 2•3 months ago
|
||
Updated•3 months ago
|
Reporter | ||
Comment 3•2 months ago
|
||
Profile from latest Nightly:
Map-heavy: https://share.firefox.dev/4f5J1Ww (4.2s)
Not map-heavy: https://share.firefox.dev/4fZ4fGX (8s)
Assignee | ||
Comment 4•2 months ago
|
||
One thing I notice is that in the non-map case we spend ~20% of our time calling js::jit::IonGetPropertyIC::update, which implies that we're repeatedly hitting the fallback for a GetProp IC because we don't have CacheIR support for something.
Digging into this, it looks like we're repeatedly accessing element -1 of an array. In general it looks like handling negative indices is kind of tricky for us. TryAttachSparseElement doesn't apply, because the PropertyKey representation requires them to be represented as the atom "-1" instead of an int32.
It feels like we could do better here. Not entirely sure how, though.
The fact that we are already better than Chrome makes this a lower priority.
Reporter | ||
Comment 5•1 month ago
|
||
Map-heavy: https://share.firefox.dev/4a81qRR
non-map-heavy: https://share.firefox.dev/3PrhBjw (8s)
(not much improvement from bug 1938518, as expected)
Assignee | ||
Comment 6•1 month ago
|
||
This makes a microbenchmark accessing arr[-1]
repeatedly 300x faster. The original "not-map-heavy" demo is noisy, but it looks like we're about 20% faster in my cut-down shell version, which is consistent with the observation that we're spending about 20% of our time in IonGetPropertyIC::update
.
This leaves Double keys uncovered. I'm not sure how often they occur.
Updated•1 month ago
|
Comment 8•1 month ago
|
||
bugherder |
Reporter | ||
Comment 9•1 month ago
|
||
Non-map-heavy: https://share.firefox.dev/4g5PdhM (~5s)
Map-heavy: https://share.firefox.dev/4heRecw (4.3s)
So we improved by about 40% from comment 5.
Comment hidden (obsolete) |
Reporter | ||
Comment 11•1 month ago
|
||
Improved Jetstream2-ai-astar by 6.2%
Reporter | ||
Comment 12•26 days ago
|
||
Non-map-heavy: https://share.firefox.dev/3PNSXd2 (6.2s) - maybe slight regression or within the noise range for 1 run?
Map-heavy: https://share.firefox.dev/4jqWknX (4.7s)
Description
•