Resizing the code-pane on Codepane demo (such that the demo redraws) spends a lot of time around GC
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
People
(Reporter: mayankleoboy1, Unassigned)
References
(Blocks 1 open bug, )
Details
Attachments
(1 file)
(deleted),
text/plain
|
Details |
Go to https://codepen.io/thebabydino/pen/mdQLYBo?editors=0010
Drag the code-pane sliders to resize the pane.
AR: The demo struggles to redraw at 60FPS. The profile suggests that during resize, the demo spends a lot of time around the GC area.
https://share.firefox.dev/3rzGkcI
Reporter | ||
Comment 1•1 year ago
|
||
Reporter | ||
Updated•1 year ago
|
Comment 2•1 year ago
|
||
Our performance should be comparable to V8, at least when testing the relevant code in a standalone shell test case:
function f() {
var u8 = new Uint8Array(1000 * 1000 * 4);
let t = performance.now();
let r = u8.reduce(function(acc, val, idx, obj) {
if (idx % 4 === 0) {
acc.push(obj.slice(idx, idx + 4));
// acc.push(val); // <-- Only this alpha pixel value is actually needed.
}
return acc;
}, []);
console.log(performance.now() - t, r.length);
}
for (let i = 0; i < 10; ++i) f();
A four-element copy of the input TypedArray is created in the reduce
callback, but the original test case is only ever using the alpha pixel value in the following filter
callback. Updating the reduce
callback to only record the alpha pixel value avoids creating these small TypedArray instances and makes the test case much faster.
(In reply to André Bargull [:anba] from comment #2)
I wonder why this is not using inline storage for a four element TypedArray.
Comment 4•1 year ago
|
||
TypedArray.prototype.slice
is self-hosted and the JIT compiler can only use inline storage when creating TypedArrays with a compile-time constant length. The computed length in TypedArray.prototype.slice
isn't a compile-time constant, therefore we use the slower MNewTypedArrayDynamicLength
instruction instead of MNewTypedArray
. And for MNewTypedArrayDynamicLength
we never try to use inline storage, but instead always malloc a new buffer in js::jit::AllocateAndInitTypedArrayBuffer
.
We could change js::jit::AllocateAndInitTypedArrayBuffer
to try to use inline storage, because the TypedArray template object is created with a zero length, which means TypedArrayObject::AllocKindForLazyBuffer
will allocate the TypedArray template using AllocKind::OBJECT8
, which means there are 32 bytes of unused space in the object.
Updated•1 year ago
|
Updated•1 year ago
|
Description
•