rstrong's blog
in search of ponies
status update – week of 12/11
December 13th, 2009 by rstrong
Progress:
- Received r+ and ui-r+ (still need to land) for – Bug 534090 [Toolkit] – do not use background notification for major updates (was PMU 3.0->3.5 major update has been really poor) [All].
- Received r+ (still need to land) – Bug 529942 [Toolkit] – Remove nsIApplicationUpdateService2 on trunk [All].
- Received r+ on a 1.9.1 patch for – Bug 407875 [Toolkit] – Unprivileged users are not notified of security updates [All].
- Received an r+ though there is still some additional work to be done on – Bug 526333 [Toolkit:Build Config] – Having to create patches for each app’s package manifest and removed-files and then get reviews from each app is a PITA [All].
- Met with dietrich, taras, mfinkle, and bhsieh regarding measuring jit JS execution times via Bug 507012 and started using the patch (which rocks) in Bug 507012 to this end.
Future targets:
- I will be focusing on silent app update as soon as I am able to finish backporting patches to 1.9.1.
Over the weekend I measured time spent on trunk in JS during startup through final-ui-startup on Windows 7 using the patch in Bug 507012 and should be able to do the same on WinCE / WinMo in the near future. I haven’t include top level calls to XPCOMUtils at present due to not having the time to associate them with their respective consumers. Even without this it is still easy to see which components need some startup love.
| File | JS_Execute | CallHooks | Total |
|---|---|---|---|
| nsExtensionManager.js | 5.940ms | 9.598ms | 15.538ms |
| nsBrowserGlue.js | 2.520ms | 9.529ms | 12.049ms |
| fuelApplication.js | 3.081ms | 0.969ms | 4.050ms |
| nsSessionStartup.js | 1.072ms | 1.625ms | 2.697ms |
| nsPrivateBrowsingService.js | 1.316ms | 0.914ms | 2.230ms |
| WebContentConverter.js | 1.629ms | 0.315ms | 1.944ms |
| nsUpdateTimerManager.js | 1.201ms | 0.440ms | 1.641ms |
| nsTryToClose.js | 0.851ms | 0.318ms | 1.169ms |
| nsUpdateServiceStub.js | 0.899ms | 0.080ms | 0.979ms |
| Total | 18.509ms | 23.788ms | 42.297ms |
Note: the first component to load (fuelApplication.js) paid a penalty of approximately 17.57ms in JS_Execute on my system which was subtracted from fuelApplication.js in the numbers above. The real time spent in JS_Execute for fuelApplication.js is 20.651ms.
Using the same build and the nsUpdateService.js from 3.6 beta 1 the time spent in app update during startup is ≅ 18.554ms compared to ≅ 2.62ms now for a total savings of ≅ 15.934 or ≅ 85%.
More needs to be done to improve the reporting / analysis and I’ll blog about this including the raw data after more progress has been made.
Edited to add a reply to a comment: “these small numbers on desktop represent large numbers on mobile and if we are able to find four similar savings it turns into around a 10% TS win on desktop since they add up quickly.” Also see The fastest code is the code that never runs for more background info.
I’m just curious: why is 16ms savings important? If all 43ms disappeared would anyone notice?
Because these small numbers on desktop represent large numbers on mobile and if we are able to find four similar savings it turns into around a 10% TS win on desktop since they add up quickly.
[...] Strong blogged about time spent executing JS in the front-end, and put up a table of the worst [...]