On Tue, Jun 13, 2017 at 11:54:17PM -0400, Boris Zbarsky wrote:
On 6/13/17 5:23 PM, Kris Maglione wrote:
For <script> tags in XUL documents, we only use a bytecode cache for
inline scripts. Other scripts are compiled off-thread from source, using
the ordinary script loader logic. Or, at least, that's my understanding
after investigating whether we could use the script precompiler for
them, to improve first paint time.
Hmm. I guess we still cache the compiled script in the
nsXULPrototypeCache but no longer do XDR for out-of-line <script>s?
That's certainly a change from the last time I looked at that code...
We used to do XDR there.
We store XDR data for XBL functions and I believe inline <script> tags
in the prototype cache, but I'm pretty sure out-of-line scripts are
loaded from omnijar as normal scripts. There might be some special
casing in the prototype cache for the second and subsequent browser
window (I'm not sure), but I checked the loads for the first window with
a debugger to make sure I understood what was going on there.
I suspect that means we should be able to use the new bytecode cache
stuff pretty transparently for those scripts, though.
Doing the per-function thing might make sense if (as I expect) most of
our chrome code is cold...
I'm not sure. It may be helpful, but there are some trade-offs, so it
could go either way. A few points to consider:
1) For the module and subscript loaders, we currently throw away sources
to save memory, and define a lazy source hook to load them on demand for
the sake of add-ons. That means we can't do lazy function compilation
for those scripts, and would have to start retaining their sources to
allow it. On the other hand, we might actually use less memory with
in-memory compressed source and lazy function compilation, but that's
not entirely clear without testing.
2) We currently pre-compile those scripts on a background thread at
startup, and in practice, they're currently nearly always ready by the
time that they're needed. So lazy compilation might not save us anything
in terms of startup speed, except on single-core/non-hyper-threaded
machines that don't spend much startup time blocked on IO.
3) With the current script pre-loader startup cache, the XDR bytecode
cache is an uncompressed, memory-mapped file that's shared between all
content processes. As currently implemented, that doesn't save us much
memory, but I'm hoping that we can take advantage of it to store
pointers directly to the cached XDR data for lazy functions, rather than
storing XDR data or compressed source code per-process.
I suspect this would give us a much bigger win for chrome code than
we'd get from using the same logic as web content, given how much chrome
code is shared across content processes vs. web content code. But it's
entirely possible that some CDN scripts are common enough that it's
worth trying to do something similar for both chrome and content XDR
caches.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
