Demo at https://dice.clockworkmod.com/ is ~2x slower in Firefox at lower iterations, and 1.2x slower at higher iterations
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
People
(Reporter: mayankleoboy1, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug, )
Details
Go to https://dice.clockworkmod.com/
Input the following and click on "Analyze" button.
100d100
- firefox: https://share.firefox.dev/4agVJmy (3.4s + 1s)
- Chrome: https://share.firefox.dev/3Kc0Euy (1.8s + 1.2s)
200d200
- Firefox: https://share.firefox.dev/43Sddli (63s + 500ms error i think)
- Chrome: https://share.firefox.dev/4oiBhoA (50s+2s)
Comment 1•10 months ago
|
||
We're spending time converting integers to JS strings for both Object.keys and for-in enumeration. That happens in this function because the dice objects can have > 500 integer property keys:
dice.prototype.keys = function() {
var ret = [];
var numbers = Object.keys(this);
for (var key in numbers) {
key = parseKey(numbers[key]);
ret.push(key);
}
return ret;
}
Bug 1502905 might help here. The keys are probably dense but not packed though, keys 0/1/2 were missing for the case I looked at.
Updated•10 months ago
|
Comment 2•9 months ago
|
||
The design in bug 1502905 won't help in this case because it depends on packed dense elements without holes.
We might be able to improve this somewhat by having a dynamic cache of strings to avoid repeatedly converting integers that don't have static strings. (Bug 1502905 also wants this cache.) If we populate the cache when enumerating dense indices (maybe with some sort of high water mark to ensure that we have requested the same string at least twice), then we could speed this case up a reasonable amount even though I don't think we will be able to cache the iterator itself.
Description
•