Firefox/Projects/Mobile Startup Shrink/Meeting July 21 2011

From MozillaWiki
Jump to: navigation, search

GOAL OF MEETING Assign tasks to people! Bugs can be made after meeting.

Getting data with telemetry Do this with your sync set up!

  • SQLite I/O https://bugzilla.mozilla.org/show_bug.cgi?id=668378
    • taking a telemetry snapshot of this right after startup would give us data
    • bug for snapshotting data after startup?
  • Tools to measure startup I/O for Android?
    • strace for Android?
    • oprofile? (ugh)
      • not good for startup
    • pcwalton's piranha?
      • not good for startup
    • perf?
      • kernel side
    • sfink's slowcalls log, see js function call tree during app startup. could spot unused/unnecessary code execution.
    • --enable-functiontimer
    • directly modify PROpen or replace all open calls
      • azakai has rewriting scripts that can do this automatically if for some reason it isn't trivial to do manually
        • let's get a bug # and a patch
        • open, read, write, fsync, perhaps stat
    • jchen has done work building android kernels
    • azakai's profiling rewriting patches measure the time of each runnable, event, ipc message, etc.
      • alon will get some data together for us
        • sub-question: can we somehow get a lower resolution version of this that could be committed and used for telemetry?
        • perhaps top 10 or so identifiers, fill in as we go

Ideas

  • Can we PGO with the new NDK?
    • jchen is working on building fennec with clang, might give some related benefits (LTO)
    • custom GCC? check with stuart?
    • owner: ben
  • CSS parsing
    • file a bug for getting telemetry data!
    • owner: taras
  • XUL reflow
    • file a bug for getting telemetry data!
    • owner: taras
  • Do we load pages before the UI is shown?
    • Nope! firstPaint happens before about home page is loaded
  • Electrolysis: process initialization
    • Does this start before first paint?
    • Someone suggested loading the child process after the UI is completely loaded, at least on single-core phones (to get at least a UI up fast)
    • owner: wes
  • Static initializers
  • Delay things until after paint
    • places initialization
    • mak thinks there's not much left in startup, except initializing DB
  • sqlite initialization OWNER: ben (P1)
    • addon manager would need to delay sqlite usage
    • password manager database
    • cookies
    • search.sqlite (search engines??)
    • form history
    • permissions.sqlite
  • nss (the only user at startup might be sync)
    • may not go through storage service
  • Incremental unzipping of libxul (would only help first-time startup?)
    • Consider after PGO work
    • Though apparently we should reconsider unzipping every time
    • And the cache is not that reliable
    • Other option is below: have a separate lib for startup
  • Re-enable unzipping of everything?
  • Reduce libxul.so size
    • by moving things we don't use during startup in a separate lib/component
      • media libraries (vpx = 116k, ogg = 6k, nestegg = 12k, tremor = 67k, theora = 38k, sydneyaudio = 4k ; overall might not be worth the bother)
      • svg (870k for libgkcontentsvg_s)
      • webgl (buried in gfx, not sure it's big, but angle is 214k)
      • uconv (714k, but we don't need all the converters until much later)
      • necko (1M, that seems like a whole lot)
      • (...)
    • by linking with gold --icf (would require a binutils newer than that in the ndk)
      • needs an owner. glandium?
      • jim/alon are trying clang/ltl
    • by removing/modifying some static variables/tables
    • by removing dead code (requires a newer binutils for --gc-sections not to break DWARF debugging info, but we can also actually remove some dead code from the codebase)
  • Serialize memory cache so we can load faster after a crash/forced shutdown (https://bugzilla.mozilla.org/show_bug.cgi?id=666340 )
  • Fastload XBL methods and properties (https://bugzilla.mozilla.org/show_bug.cgi?id=94199 )
  • Prelinking libraries
    • Not necessarily a good idea from a security POV, though there's currently no ASLR
      • Prelinking can be done at install time to accommodate any ASLR
        • It can't when we don't have a library cache (i.e. when there is not enough storage space). And we don't populate the library cache at install time. Prelinking is also not compatible with elfhack, and doesn't buy much if i remember correctly the relocation timings.
  • Precompile startupcache (requires to run xpcshell on a device)
  • Can we reduce the time spent before reaching into our guts ? (from experimentation on a Nexus S, it looks like there are 200ms (!) spent between the ActivityManager starting the intent and us actually starting to load libxul).
    • Maybe the NDK would allow us to implement the intention in C++?
    • May be useful for forking the process
    • May be useful to not load Java until first paint
    • Taras thinks valgrind might work better with no Java
    • needs an owner

"Cheating" aka. perceived performance

Action Items

Retrieved from "https://wiki.mozilla.org/index.php?title=Firefox/Projects/Mobile_Startup_Shrink/Meeting_July_21_2011&oldid=332226"