1888768 - AST explorer spends a lot of time in PostWriteBarrier(although we are as fast as Chrome here)

Status: NEW

(Core :: JavaScript Engine, task, P3)

Description

[Mayank Bansal]

Go to https://astexplorer.net/
From the top bar, select "Markdown" as the input language

Copy and paste the attached sample text.

Nightly: https://share.firefox.dev/3TH9xga (5.5s)
Chrome: https://share.firefox.dev/49hsYBW

Maybe something to improve?

Comment 1

[Mayank Bansal]

Attachment: moz bundle.js

Comment 2

[Mayank Bansal]

And here is a profile for a larger sample text file : https://share.firefox.dev/3xhDRGK

Comment 3

[Iain Ireland [:iain]]

Looks like 32% of our active time is being spent in js::NativeObject::elementsRangePostWriteBarrier, which scans through a range of elements looking for the first nursery-allocated object and adds the remaining chunk of the range after it finds one. This should be fast if we're hitting quickly, so it's likely that there are few (or no) nursery-allocated objects in this range, in which case we will scan the entire range.

I haven't actually dug into the source code of the website, but it seems likely that we're repeatedly calling array.splice with a very large array. If we aren't introducing any new nursery allocations, then after the first minor GC everything will be tenured and we will do the full scan every time.

We could maybe consider capping the length of the scan that we're willing to do. For example, maybe we only scan 1000 elements, and then after that, even if we haven't found a nursery object, we add the remaining range to the store buffer. But that might just push the work to GC time instead.