rstrong's blog
in search of ponies
The fastest code is the code that never runs
November 29th, 2009 by rstrong
The really short version:
On WinCE Firefox the average time spent in application update’s JavaScript components during startup was ≅ 181 ms and after Bug 311965 landed it was ≅ 51 ms… ≅ 72% savings. This was accomplished by creating a separate component that performed the bare minimum of work during startup. This is on top of previous work that reduced application update startup time on Maemo Fennec from ≅ 200 ms to ≅ 150 ms which is ≅ 25% savings. Altogether the total improvement taking into account the earlier work on application update on WinCE Firefox is ≅ 175 ms or ≅ 77%.
The longer (though still short) version:
On mobile platforms almost all code is quite a bit more expensive than on desktops where the OS / hardware optimizes around the performance costly areas and when all of our current tools for measuring performance focus on the desktop platforms it is difficult to give the mobile platforms performance work a high priority. For me, it is a case of “out of sight, out of mind”. How should this be resolved? First and foremost we need stable performance numbers for at least one mobile platform. It would also be extremely helpful if developers had access to more detailed info regarding the time spent in each component during startup especially if it was available from the try servers. This data can be had when using the patch from Bug 470116 [Core] – Component for timing execution of js and others [Linux] but few developers have this hardware available. As I understand it Bug 480735 [Core] – Startup timeline [All] also provides this data but I can’t confirm this since I used the patch in Bug 470116 for performance measurements.
Over the years a lot of code has been bolted on to application update to provide additional functionality without taking into consideration the affect the changes would have on startup. For example, on Vista there were multiple write access checks that in some cases were for the same directory. This sounds bad but on desktops the affect was so slight that it was less than the noise factor in our performance tests so it really was negligable in the pre-mobile days. Prior to rafactoring the update service by using a stub I reviewed the existing code and optimized it as appropriate so the case where the application update component processes an update is faster too. This is the reverse of my normal approach of taking the low hanging fruit and then spending an inordinate amount of time finding the little wins. I took this approach since there are always plenty of things to fix and it would have been very easy to just keep putting off optimizing this code especially since it would have been taken out of the common startup path.
Prior to Bug 311965 landing application update only had the nsUpdateService.js file and now it has the nsUpdateService.js, nsUpdateServiceStub.js, and nsUpdateTimerManager.js files with only nsUpdateServiceStub.js and nsUpdateTimerManager.js being loaded on startup for the normal case. As a side benefit if the application is built with “ac_add_options –disable-updater” nsUpdateService.js, nsUpdateServiceStub.js, and the updater binary are not built which improves startup on Maemo Fennec by an additional ≅ 12 ms which was changed in Bug 530393 [Fennec] – Don’t build updater code for Maemo. Though having less files is important for the cold startup case having more files can drastically improve startup when the application has a fastload file and the stub file performs a small amount of work as compared to a large file that takes longer to load and evaluate.
It turns out that js_execute tends to be what hurts most during startup and there is Bug 522354 [Core] – investigate why we spend a long time js_execute()ing things [Linux] to investigate this. I hope that time spent in js_execute can be improved but this in no way negates the need to re-evaluate time spent in startup for all JavaScript components… I can’t imagine Bug 522354 being some sort of silver bullet for improving startup time and I highly suspect any work done in JavaScript components to improve startup time will still be applicable even with any improvements provided by Bug 522354 or other bugs.
When it comes to mobile disk IO is the thing most often stated when it comes to startup performance. I know disk IO on mobile has a hefty cost but it is way too easy to focus on disk IO and skim over everything else. The initial patches to improve performance for application update focused mostly on lessening disk IO and they did improve startup significantly (around 25%) but no where near as much as using a stub for the service. For example, prior to the application update refactoring I had removed the write access checks for WinCE to improve startup performance and was able to add them back with the stub while still being able to improve startup performance.
Now I try to forget about the desktop when optimizing especially for small improvements… Talos will catch regressions / improvements on the desktop but the noise in the numbers is such that it is impossible to catch small improvements. On a mobile device it is quite clear whether a change has improved or regressed startup. For example, the 131 ms improvement I measured on WinCE Firefox appeared to improve startup on desktop by a couple of ms on Talos desktop though that is well within the noise. Once again, it would be extremely helpful to developers if this information was available for mobile via the tinderboxen and the try servers.
There is still a ton of work to be done on the low hanging fruit… just take a look at the numbers from sample WinCE Firefox log. For example…
components/nsBlocklistService.js – 356 ms
components/nsExtensionManager.js – 338 ms
components/nsBrowserGlue.js – 211 ms
Thanks go out to Taras for patiently answering my questions and providing me with data as I slowly acquired a more mobile orientated mindset along with his own work to improve startup performance for everyone by improving the core of Mozilla and to dietrich for taking on making startup performance improvement a primary goal for the Firefox team.
[...] Strong put up a detailed post about his startup improvements to the update service, the effect on mobile, and pointed out some [...]
[...] 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 [...]