109
edits
Firefox/Projects/Startup Time Improvements/joelr notes: Difference between revisions
Jump to navigation
Jump to search
Firefox/Projects/Startup Time Improvements/joelr notes (view source)
Revision as of 16:30, 26 August 2009
, 26 August 2009no edit summary
Joel Reymont (talk | contribs) No edit summary |
Joel Reymont (talk | contribs) No edit summary |
||
| Line 4: | Line 4: | ||
= Current status = | = Current status = | ||
=== August 26, 2009 === | |||
Suppose we sample at about 1Khz on a dual-core CPU and run an app for 10 seconds. An app that hogs the CPU should give us 20k samples, or 10k samples if it's pegged to a single core. | |||
I coded this up in a [http://github.com/wagerlabs/firefox-startup/blob/0daf8a950b91e8d9c24187d54b04fb51f2764490/cpu.d cpu.d] DTrace script and sampled Firefox. Apparently, Firefox only gets ~1700 samples on the CPU or 1.7s so its first 10 seconds of life are spent doing something else, e.g. disk IO. | |||
We already know that Firefox is slow to start up but this type of sampling neatly points the finger in the right direction. Props to Brendan Gregg for teaching me to fish! | |||
= Previous statuses = | |||
=== August 25, 2009 === | === August 25, 2009 === | ||
| Line 10: | Line 20: | ||
''pid$target::function:entry'' probes are very slow since DTrace may have to search thousands of functions. All that search time skews elapsed time reported by ''timestamp''. USDT (static) probes are just a few NOP instructions in the code that get fixed up by DTrace as needed so they work much faster. | ''pid$target::function:entry'' probes are very slow since DTrace may have to search thousands of functions. All that search time skews elapsed time reported by ''timestamp''. USDT (static) probes are just a few NOP instructions in the code that get fixed up by DTrace as needed so they work much faster. | ||
=== August 24, 2009 === | === August 24, 2009 === | ||