Firefox/Projects/Startup Time Improvements: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 83: Line 83:
* [http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/42c0e9df84b935fe what is fastload?]
* [http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/42c0e9df84b935fe what is fastload?]
* [http://kb.mozillazine.org/Nglayout.debug.disable_xul_fastload fastload pref docs]
* [http://kb.mozillazine.org/Nglayout.debug.disable_xul_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 <code>dom.allow_scripts_to_close_windows</code> and <code>browser.dom.window.dump.enabled</code> to true in your testing profile
** run it in a loop to collect more stable results:
<pre style="white-space: pre-wrap">
#!/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;
</pre>

Revision as of 23:23, 22 July 2009

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
    • 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
  • Mine bugzilla for existing startup bugs and tag them (Dietrich)
  • Hot vs. cold testing
    • Running with fastload crippled/disabled

References

Meta-bugs and Searches

Needs investigation

Previous work

Tips, Tools

Fastload:

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_windows and browser.dom.window.dump.enabled to 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;