1555522 - Enable JavaScript Startup Bytecode Cache for DevTools code

Status: NEW

(Core :: JavaScript Engine, enhancement, P2)

Description

[:Harald Kirschner :digitarald]

Speeding up initial panel opening is DevTools' #1 performance goal based on user feedback.

Parse and compile shows up heavily in DevTools opening (Inspector http://bit.ly/2KaVM7u) and tab switching (to Debugger: http://bit.ly/2K97oYA) profiles.

:tcampbell confirmed that DevTools currently benefits from neither the startup not the bytecode cache (necko only). This work might also benefit other Firefox features of Firefox that have to load big JS bundles.

Comment 1

[Ted Campbell [:tcampbell]]

Thanks for the profiles!

It looks like I was partially mistaken. Since the devtools stuff you are concerned about is in the parent process, we do get the assistance of the startupcache. See "StartupCache::GetBuffer" (and more precisely, "js::XDRState::codeScript") in the profiles you linked.

It is nice that we have the startupcache kicking in, but it also doesn't make use of off-thread. For example, in the browser-startup case, we have a preloadcache that will use a helper thread to run decode processes before they are requested. A similar architecture would greatly help parts of this profile. The difficulty is that there trickiness around profile/cache corruption, security model of persisted bytecode, timing of when to start the decode, etc.

The second half of the tab-switch profile seems to be related to sourcemap / sources handling which I'm told already has discussion around what to do. I do see about 5-10% time in LookupName which is likely related to discussion in Bug 1430656. Probably worth a discussion again in Whistler.

Comment 2

[Steven DeTar [:sdetar]]

I am going to give this a priority of P2 for now. We can discuss in Whistler and change as necessary.

Comment 3

[Nicolas B. Pierron [:nbp]]

I concur with Ted, the profiles seems to already be using the bytecode cache (filter: XDR) instead of the JS parser (filter: frontend)

Inspector http://bit.ly/2KaVM7u : XDR 38.5 ms ; frontend 1.0 ms.
Debugger: http://bit.ly/2K97oYA : XDR 49.5 ms ; frontend 2.5 ms

As Ted pointed out, the Startup cache are compressed and you should include in the previous results the fact that the buffers should be deflated. (StartupCache::GetBuffer 56ms in Debugger: http://bit.ly/2K97oYA )