Overview
Sprint lead: Dietrich Ayala
Sprinters: Ryan Flint, Drew Willcoxon, David Dahl
Concurrent work: Vlad Vukićević, Taras Glek
Description: Investigate areas for improving startup time of the Mozilla platform, find & fix issues that help Fennec and WinCE.
Phase 1: Exploration 7/13 - 7/24, Achieve visibility into the performance-related problem areas during browser startup, and to use that visibility to create actionable bugs, creating a clear development path to move forward on.
Phase 2: Seek and Destroy 7/27 - 8/7, More research into causes of I/O usage, and evaluation of approaches for large-scale mitigation. Fix bugs in which a resolution path is already clear, and that would provide a human-noticeable win in Fennec or WinCe. For areas not immediately fixable, file bugs and ensure that the relevant people are aware of the problem, and work to get those bugs with potentially big wins prioritized.
Bug visibility
We've been using "[ts]" in the whiteboard field for our newly filed bugs as well as pre-existing.
- Meta bugs
- bug 459117 Fennec performance meta bug
- bug 447581 Startup meta bug
- bug 479078 Startup research meta bug
- bug 7251 very old startup meta bug
Instrumentation
Create an easily accessible timeline of the startup path (David, Vlad)
- Status: in progress
- Usage: steps here
- Results
- bug 480735 instrumentation
- bug 503605 visualization
- Example output: Simile timeline
- Example output: raw log
Mine the Ts DTrace viz/logs (Drew)
- Status: complete, moved on to filesystem operations below
- Results
- It's my conclusion that (cold) startup is heavily I/O-bound. Something like 90% of cold startup time is spent in page faults and other I/O syscalls, especially read, getattrlist, and stat. And the majority of time spent after Firefox actually gets up and running is in XBL and CSS. Any improvements that ignore these observations will therefore be marginal IMO.
- Bugs
- bug 504858 - Investigate delaying initialization of bookmarks toolbar
- bug 504872 - Investigate further delaying initialization of the search bar
- I think these two bugs aren't worth pursuing. As Gavin comments in them, the latency I noticed is due to unavoidable things like XBL attachment and flushing layout. Moreover, they contribute very, very little to startup time.
Log and mine filesystem operations during startup (Ryan, Drew)
- Status: in progress
- Todo
- maybe write a new dtrace script for targeting offenders
- Results
- checking out Xperf and others for Windows work
- investigating dtrace timing/FS cache issues on OS X
- Instruments appears to have the same issues
- Simple JS file exec script has yielded some results
- investigating dtrace timing/FS cache issues on OS X
- Drew's notes
- checking out Xperf and others for Windows work
- References
- Josh Aas's post
- Taras' post on using GDB for logging
- Firefox/Projects/Startup_Time_Improvements/IO_Scratchpad
Static Analysis
Find dead code with JSHydra (David Dahl)
- Status: in progress
- Todo
- Results
- Bugs
- bug 506128 - run jshydra to find js functions that have no callers
Testing
Dirty profile testing (Alice, David Dahl, Dietrich)
- Status: in progress
- Todo
- Create various scenarios to measure
- sessions, downloads, cookies, urlclassifier data
- Fix date updater for med/large profiles
- Roll-up reporting of results
- Create various scenarios to measure
- Results
- Builds marked "dirty" on the test tree
JSHydra continuous testing
- Status: not started
- Todo
- Feasibility analysis: need to find out if even possible
- Determine test scenarios
- ending semicolon bug (XXX)
- dead code finder
Miscellaneous Improvements
Notes, other ideas to develop further, bugs to file, etc.
TODO:
- enumerate findings, convert to best practices recommendation
- user-runnable Ts script
- paste into js console
- restarts browser, passing last known time
- loads data URI that reads startup time and prints it out
- record startup timestamp as a pref?
Bugs:
- FILEME - minification packaging step
- bug 507101 - component combining packaging step
- bug 509755 - modules into jar file packaging step
- FILEME - micro-benchmark tests
- see also the mochitests i wrote for this (find the places bug for this)
- FILEME - dirty test (or micro?): need test for opening the 80th tab for example
- FILEME - tracing/trace-ability reporting
- traceviz (bug 497999)
- FILEME - other dirty profiles
- sessions, downloads, urlclassifier data, post-crash session
- sql query count measurement (find my bug for this)
Notes:
- Hot vs. cold testing: running with fastload crippled/disabled
- Needs investigation: string pool for jsxpcom
References
- Taras' Fennec Startup Work
- bug 459117 "make fennec faster", mostly startup bugs
- startup log
- bug 470116 various timing scripts
Tips, Tools
- Flushing Windows' disk cache
- Flushing Mac OS X's disk cache
- Firefox/Projects/Startup_Time_Improvements_Notes: Vlad's emails about cold startup, including Linux (maybe move this info to this page)
- DTrace
- nuts and bolts how-to for getting dtrace running with mozilla
- project overview of integrating dtrace with mozilla
- dtrace community page, lots of links
- dtrace homepage? not as useful as previous link
- intro from dtrace guidebook, really useful but not mozilla/js-specific
- brief descriptions of the javascript* probes
- David Mandelin's notes on tracing C++ code
Fastload
- why does js_Execute take so long for fastloaded components?
- what is fastload?
- fastload pref docs
Measuring Ts
- startup-unix.pl in mozilla/tools/performance/startup
- edit it to use this HTML in place of startup-test.html:
<html>
<body onload="
var now = (new Date()).getTime();
var begin = document.location.search.split('=')[1]; // ?begin=nnnnn
dump((now - begin) + '\n');
window.close();
">
</body>
</html>
- set
dom.allow_scripts_to_close_windowsandbrowser.dom.window.dump.enabledto true in your testing profile - run it in a loop to collect more stable results:
- set
#!/bin/bash cd ~/moz/trunk/mozilla/tools/performance/startup for ((i=0; i < 5; i++)) do perl startup-unix.pl ~/moz/trunk/build-dbg/dist/MinefieldDebug.app/Contents/MacOS/firefox-bin -P startup >> results.txt; done;