Profile: https://perfht.ml/2xNSt1O (look for mozilla::Omnijar::InitOne)

GeckoView startup currently spends around 440ms of CPU time decompressing the omnijar out of the APK: 255ms in the parent process, and then another 185ms in the content process. This happens at the very beginning of the process lifetime.
(The omnijar is a nested archive; decompressing individual entries from inside the omnijar happens on demand as those entries are needed.)

Can we avoid this initial decompression? It seems Gradle supports stuffing files into the APK without compression. So it seems that we could just have the omnijar data itself mapped into memory from the mapped apk file, or something?

This would supersede bug 1620445.

For Fennec this was handled via the old ./mach package infrastructure, respectively for local builds in bug 1428128.

I'm not sure if anything changed since then regarding the possibilities offered by the Android build system, but at least at that time it was the case that the aaptOptions could only be set by the application and not at the library-level, so the only choices would be

• all GeckoView consumers manually need to add noCompress 'ja' to their aaptOptions, or
• we provide a custom GeckoView Gradle plugin that does this for us (though GeckoView consumers might still have to explicitly remember adding the plugin instead... - or is there some way to make the build fail unless our custom plugin has been included?)

Yeah I think adding noCompress 'ja' should be enough for now.

:mstange and I looked into this more today. Sounds like adding noCompress is the only thing needed here as our zip code should already be smart enough not to expand a STORE file in a zip. I'll open an issue on Fenix.

Yes, I confirmed that adding that line to GeckoView_example's build.gradle does the trick for GeckoView example.
Before: https://perfht.ml/3blMrE9
After: https://perfht.ml/2WyNwo2
No more time spent in Omnijar::InitOne.

Fenix issue: https://github.com/mozilla-mobile/fenix/issues/9333

The omni.ja file contains all the javascript code that GeckoView uses
internally. Right now the omni.ja file is compressed in the APK which causes
GeckoView to uncompress the omni.ja file in memory before it can start doing
anything else. This takes a long time, on some profiles it delays startup by
about 400ms.

Storing the omni.ja uncompressed allows GeckoView to just map it in memory
bypassing the uncompress step.

https://hg.mozilla.org/mozilla-central/rev/749fac2ed074

Before/after profiles for Fenix: https://perfht.ml/2xNSt1O / https://bit.ly/2QKnEln

The first content network request starts around 200ms earlier than before. That's great but it's only about half of the expected 440ms. The reason seems to be that random other things within the first ~second have gotten slower: E.g. the "script emit" part of the self-hosted JS code (bug 1618391) is taking twice the time compared to before.
I think what's happening is that there's other stuff running early during startup, on other threads, taking away CPU resources. We should keep this in mind when we predict the impact of eliminating early-startup work: The actual impact might only be half of what the wall-clock time in the profiler shows. This demonstrates why it can be useful to look at on-thread-CPU time rather than wall-clock time. (Bug 1329600 tracks adding this information to the Gecko profiler.)