Firefox/Projects/Startup Time Improvements
Jump to navigation
Jump to search
Overview
Sprint lead: Dietrich
Sprinters: Ryan, Drew, David
- Description
- Investigate areas for Ts wins, find & fix issues that help Fennec and WinCE
Goals / Use Cases
- The core goal of this sprint is to 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.
- The secondary goal is to fix bugs in which a resolution path is already clear, and that would provide a human-noticeable win in Fennec or WinCe.
- Non Goals
- Fix all the identified areas. Should ensure that the relevant people are aware of bugs filed, and work to get the bugs with potentially big wins prioritized.
Plan
- Create a baseline profile for testing
- Create and document measurement tools and strategies
- Identify code paths that take the most time at startup
- File bugs for problems found to be actionable
Tasks
- Define the test environment
- Create a baseline profile to measure startup against (Dietrich)
- Prefs, platform-specific issues
- Create an easily accessible timeline of the startup path (David)
- STATUS (2009-07-21): Compiling and linking. We needed to use NS_COM instead of NS_EXPORT. (I would like to know why/how/etc.)
- HOW TO USE THIS PATCH: [1]
- Split the patch up into 3 patches for easier review: CPP, JS and Instrumentation
- Mine the Ts DTrace visualization for opportunities (Drew)
- bug 504858 - Investigate delaying initialization of bookmarks toolbar
- bug 504872 - Investigate further delaying initialization of the search bar
- See DTrace links below also
- Log and mine filesystem operations during startup (Ryan)
- Josh Aas's post
- Taras' post on using GDB for logging
- checking out Xperf and others for Windows work
- maybe write a new dtrace script for targeting offenders
- 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
- Firefox/Sprints/Startup_Time_Improvements/IO_Scratchpad
- Mine bugzilla for existing startup bugs and tag them (Dietrich)
- Hot vs. cold testing
- Running with fastload crippled/disabled
References
Meta-bugs and Searches
- bugs with ts whiteboard
- bug 479078 contemporary startup meta bug
- bug 447581 not-much-used startup meta bug
- bug 7251 old school startup meta bug
Needs investigation
- string pool for jsxpcom: https://bugzilla.mozilla.org/show_bug.cgi?id=279839#c29
Previous work
- Startup Timeline: bug 480735
- Visualize Startup Timeline bug 503605
- Vlad's June posting on startup work
- zpao's JS treemap visualizations
- Taras' Fennec Startup Work
- bug 459117 "make fennec faster", mostly startup bugs
- startup log
- bug 470116 various timing scripts
- Performance:Home_Page
Tips, Tools
- Flushing Windows' disk cache
- Flushing Mac OS X's disk cache
- 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
Fastload
- why does js_Execute take so long for fastloaded components?
- what is fastload?
- fastload pref docs
Measuring Ts
- starup-unix.pl in mozilla/tools/performance/startup
- edit it to use http://pastebin.mozilla.org/663935 in place of startup-test.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:
#!/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;
Scratchpad
- convert browser/utils.js to a module, memoized getter in the overlay
- have any bookmark/history observers be category observers
- lazy load DownloadUtils.jsm in browser.js (global memoized getter array for imports?)
- memoized getter for PluralForm.jsm inside DownloadUtils.jsm
- #define out all the LOG functions
- nsiupdate check - if wince, always have write access, so don't need checks
- n810?
- consolidate the zillion redundant getService calls in browser.js
- shortcut newURI(str) in browser.js
- does FeedWriter need to be a component? (see bug 336903)
- remove the inclusion of debug.js from everywhere
- remove all the log() functions (or move it to debug.js)
- globalOverlay.js:isValidLeftClick has no callers
- globalOverlay.js:FillInTooltip's only caller is http://mxr.mozilla.org/mozilla-central/source/toolkit/obsolete/content/globalOverlay.xul
- globalOverlay.js:goOnEvent has no callers
- unused: http://mxr.mozilla.org/mozilla-central/source/toolkit/obsolete/content/globalOverlay.xul
- globalOverlay.js:visitlink() only used in credits.xhtml
- globalOverlay.js:goSetAccessKey() has no callers
- globalOverlay.js:goSetMenuValue() has no callers
- can globalOverlay.js be removed altogether?
- run jshydra to find js functions that have no callers
- cookies.sqlite writes to disk constantly
- expose raw access to C types for safe/simple properties in xpcom (bug 412531, bug 505907)