Open Bug 1845242 Opened 1 year ago Updated 1 year ago

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)

task

Tracking

()

People

(Reporter: mayankleoboy1, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file)

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

Attached file about:support (deleted) —
Summary: Resizing the code-pane on Codepane demo spends a lot of time around GC → Resizing the code-pane on Codepane demo (such that the demo redraws) spends a lot of time around GC

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.

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.

Severity: -- → S3
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: