Firefox/Projects/Startup Time Improvements: Difference between revisions
Jump to navigation
Jump to search
(→Tasks) |
(→Tasks) |
||
| Line 29: | Line 29: | ||
* Create an easily accessible timeline of the startup path (David) | * 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.) | *** 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: [StartupPatchUsage] | *** HOW TO USE THIS PATCH: [https://wiki.mozilla.org/Firefox/Sprints/Startup_Time_Improvements/StartupPatchUsage#Quick_Start] | ||
*** Split the patch up into 3 patches for easier review: CPP, JS and Instrumentation | *** Split the patch up into 3 patches for easier review: CPP, JS and Instrumentation | ||
* Mine the Ts DTrace visualization for opportunities (Drew) | * Mine the Ts DTrace visualization for opportunities (Drew) | ||
Revision as of 22:29, 21 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
- investigating dtrace timing/FS cache issues on OS X
- 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 treemap visualizations
- 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
- 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