зеркало из https://github.com/mozilla/gecko-dev.git
Read-only Git mirror of the Mercurial gecko repositories at https://hg.mozilla.org. How to contribute: https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
a4368ffba1
One of the things that I've noticed in profiling startup overhead is that, even with the startup cache, we spend about 130ms just loading and decoding scripts from the startup cache on my machine. I think we should be able to do better than that by doing some of that work in the background for scripts that we know we'll need during startup. With this change, we seem to consistently save about 3-5% on non-e10s startup overhead on talos. But there's a lot of room for tuning, and I think we get some considerable improvement with a few ongoing tweeks. Some notes about the approach: - Setting up the off-thread compile is fairly expensive, since we need to create a global object, and a lot of its built-in prototype objects for each compile. So in order for there to be a performance improvement for OMT compiles, the script has to be pretty large. Right now, the tipping point seems to be about 20K. There's currently no easy way to improve the per-compile setup overhead, but we should be able to combine the off-thread compiles for multiple smaller scripts into a single operation without any additional per-script overhead. - The time we spend setting up scripts for OMT compile is almost entirely CPU-bound. That means that we have a chunk of about 20-50ms where we can safely schedule thread-safe IO work during early startup, so if we schedule some of our current synchronous IO operations on background threads during the script cache setup, we basically get them for free, and can probably increase the number of scripts we compile in the background. - I went with an uncompressed mmap of the raw XDR data for a storage format. That currently occupies about 5MB of disk space. Gzipped, it's ~1.2MB, so compressing it might save some startup disk IO, but keeping it uncompressed simplifies a lot of the OMT and even main thread decoding process, but, more importantly: - We currently don't use the startup cache in content processes, for a variety of reasons. However, with this approach, I think we can safely store the cached script data from a content process before we load any untrusted code into it, and then share mmapped startup cache data between all content processes. That should speed up content process startup *a lot*, and very likely save memory, too. And: - If we're especially concerned about saving per-process memory, and we keep the cache data mapped for the lifetime of the JS runtime, I think that with some effort we can probably share the static string data from scripts between content processes, without any copying. Right now, it looks like for the main process, there's about 1.5MB of string-ish data in the XDR dumps. It's probably less for content processes, but if we could save .5MB per process this way, it might make it easier to increase the number of content processes we allow. MozReview-Commit-ID: CVJahyNktKB --HG-- extra : rebase_source : 2ec24c8b0000f9187a9bf4a096ee8d93403d7ab2 extra : absorb_source : bb9d799d664a03941447a294ac43c54f334ef6f5 |
||
|---|---|---|
| .cargo | ||
| .vscode | ||
| accessible | ||
| addon-sdk | ||
| browser | ||
| build | ||
| caps | ||
| chrome | ||
| config | ||
| db | ||
| devtools | ||
| docshell | ||
| dom | ||
| editor | ||
| embedding | ||
| extensions | ||
| gfx | ||
| gradle/wrapper | ||
| hal | ||
| image | ||
| intl | ||
| ipc | ||
| js | ||
| layout | ||
| media | ||
| memory | ||
| mfbt | ||
| mobile | ||
| modules | ||
| mozglue | ||
| netwerk | ||
| nsprpub | ||
| other-licenses | ||
| parser | ||
| probes | ||
| python | ||
| rdf | ||
| security | ||
| services | ||
| servo | ||
| startupcache | ||
| storage | ||
| taskcluster | ||
| testing | ||
| third_party/rust | ||
| toolkit | ||
| tools | ||
| uriloader | ||
| view | ||
| widget | ||
| xpcom | ||
| xpfe | ||
| .clang-format | ||
| .clang-format-ignore | ||
| .clang-tidy | ||
| .cron.yml | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .flake8 | ||
| .gdbinit | ||
| .gdbinit_python | ||
| .gitignore | ||
| .hgignore | ||
| .hgtags | ||
| .inferconfig | ||
| .lldbinit | ||
| .taskcluster.yml | ||
| .ycm_extra_conf.py | ||
| AUTHORS | ||
| Android.mk | ||
| CLOBBER | ||
| GNUmakefile | ||
| LEGAL | ||
| LICENSE | ||
| Makefile.in | ||
| README.txt | ||
| aclocal.m4 | ||
| build.gradle | ||
| client.mk | ||
| client.py | ||
| configure.in | ||
| configure.py | ||
| gradle.properties | ||
| gradlew | ||
| mach | ||
| moz.build | ||
| moz.configure | ||
| mozilla-config.h.in | ||
| npm-shrinkwrap.json | ||
| old-configure.in | ||
| package.json | ||
| settings.gradle | ||
| test.mozbuild | ||
README.txt
An explanation of the Mozilla Source Code Directory Structure and links to
project pages with documentation can be found at:
https://developer.mozilla.org/en/Mozilla_Source_Code_Directory_Structure
For information on how to build Mozilla from the source code, see:
https://developer.mozilla.org/en/docs/Build_Documentation
To have your bug fix / feature added to Mozilla, you should create a patch and
submit it to Bugzilla (https://bugzilla.mozilla.org). Instructions are at:
https://developer.mozilla.org/en/docs/Creating_a_patch
https://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree
If you have a question about developing Mozilla, and can't find the solution
on https://developer.mozilla.org, you can try asking your question in a
mozilla.* Usenet group, or on IRC at irc.mozilla.org. [The Mozilla news groups
are accessible on Google Groups, or news.mozilla.org with a NNTP reader.]
You can download nightly development builds from the Mozilla FTP server.
Keep in mind that nightly builds, which are used by Mozilla developers for
testing, may be buggy. Firefox nightlies, for example, can be found at:
https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
- or -
https://nightly.mozilla.org/