1950480 - Off thread script parse is slower than on the main thread (50ms for raptor wikipedia).

Status: NEW

(Core :: JavaScript Engine, enhancement, P3)

Description

[Thinker Li [:sinker]]

According to bug 1786466, off thread compilation takes too long, the main thread is waiting for it. I tried to disable Off thread compilication by replacing Kind::OffMainThreadOnly with Kind::MainThreadOnly for CompileOrDecodeTask, and it reduce to ~50ms from ~100ms. (Check markers ScriptCompileOffThread for https://en.m.wikipedia.org/w/load.php?. Off thread: https://share.firefox.dev/42VXjGI , Not Off thread: https://share.firefox.dev/3EG8rO8 ) I have ran the test for several times. The difference is pretty consistent.

The test base on the raptor wikipedia test case with Pixel 9.

• https://bugzilla.mozilla.org/show_bug.cgi?id=1786466#c7

Comment 1

[Thinker Li [:sinker]]

Redo profiling with '--enable-release', the results are similar. OffMainThreadOnly:MainThreadOnly is 89.1ms:46.9ms.

OffMainThreadOnly: https://share.firefox.dev/4irEUX5
MainThreadOnly: https://share.firefox.dev/4btVW4g

Comment 2

[Matthew Gaudet (he/him) [:mgaudet]]

Ok, CompileOrDecode task is DOM ScriptLoader, which I think is distinct from the JS Off-thread compilation. The change you reference being made here.

ScriptCompileOffThread - <script async src="https://en.m.wikipedia.org/w/load.php ..."> is the compile under discussion.

I think that we're using script async as the hint that this should happen.

// TODO: This uses the same heuristics and the same threshold as the
//       JS::CanCompileOffThread / JS::CanDecodeOffThread APIs, but the
//       heuristics needs to be updated to reflect the change regarding the
//       Stencil API, and also the thread management on the consumer side
//       (bug 1846160).
static constexpr size_t OffThreadMinimumTextLength = 5 * 1000;

Is I suspect pretty key here, though there are -many- knobs here (see for example this heuristic)

The change you make is a pretty big hammer, and I have a sneaking suspicion that there would be some places this would regress even if it provides progression in this case.

I sort of feel like tuning OffThreadMinimumTextLength (and making into a tunable pref) would be a good next step here. It's possible what's happening here is that off-thread parse (on android only?) is more costly than we figured, and need to tune this.

Comment 3

[Markus Stange [:mstange]]

The slowness is probably due to a different core type. Android is probably putting the background thread on a small core and the main thread on a big core.

I'm not sure there's anything worth fixing for this Wikipedia case in particular. Off-main thread script compiles allow the main thread to do other work that's often of higher importance. For scripts that we identify as something we really need "as soon as possible", we should put them on a thread that's marked with a high performance class of service (waving my hands a bit here), but load.php on wikipedia doesn't appear to be latency sensitive script because the page renders completely before the script is compiled.

Off-thread: https://share.firefox.dev/4ib9ioG
On-thread: https://share.firefox.dev/4kvR036

In the on-thread profile, the screenshot track shows the image being painted before the script is done compiling.