Last Comment Bug 724177 - 30-50ms (5%) Firefox startup speed optimization on Windows in nsLocalFileWin
: 30-50ms (5%) Firefox startup speed optimization on Windows in nsLocalFileWin
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: Trunk
: All Windows 7
: -- normal (vote)
: mozilla13
Assigned To: Brian R. Bondy [:bbondy]
:
Mentors:
Depends on: 716174
Blocks: 545650
  Show dependency treegraph
 
Reported: 2012-02-03 17:10 PST by Brian R. Bondy [:bbondy]
Modified: 2012-02-07 12:14 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Startup time opt breakdown (71.46 KB, image/png)
2012-02-03 17:10 PST, Brian R. Bondy [:bbondy]
no flags Details
Patch v1. (4.18 KB, patch)
2012-02-03 17:10 PST, Brian R. Bondy [:bbondy]
jmathies: review+
Details | Diff | Splinter Review

Description Brian R. Bondy [:bbondy] 2012-02-03 17:10:26 PST
Created attachment 594368 [details]
Startup time opt breakdown

I was profiling nsLocalFileWin and noticed a slowdown on Windows startup.
About 30-60ms was spent copying a single file on startup.

The file copy happens on the *main thread*.
The file that is copied is sessionStore.js to sessionstore.bak.
The file is <1KB on my profile and tests, but I've seen this file up to 400KB on my other unused profiles.

The slowdown happens after mozilla::StartupTimeline::FIRST_PAINT but before StartupTimeline::SESSION_RESTORED.
The slowdown was completely removed and accounted for 30ms-60ms of startup time.

Bug 545650 introduced the no buffering flag when copying files to solve a bug for network drives.  This landed in March 2011.  On startup, we use the flag for copying sessionstore to a backup location, and this location is not on a network drive.

With the flag the copy takes 30-60ms.  Without the flag the copy takes less than 1ms.

I've noticed this file copy operation using xperf in the past, but this optimization was done using my local simple profiler independent of that.

I confirmed these findings using the about:startup extension.
The 20 run average for session restored is 1016.27 vs 963.14 (53.13ms savings)
Please see the attached screenshot for a breakdown.
Comment 1 Brian R. Bondy [:bbondy] 2012-02-03 17:10:53 PST
Created attachment 594370 [details] [diff] [review]
Patch v1.
Comment 2 Kyle Huey [:khuey] (khuey@mozilla.com) 2012-02-03 17:35:32 PST
See also Bug 716174.
Comment 3 Brian R. Bondy [:bbondy] 2012-02-03 17:47:35 PST
Thanks for the heads up khuey, I put some info in that bug about the post effects after this lands.
Comment 4 Brian R. Bondy [:bbondy] 2012-02-03 17:50:27 PST
jimm: I tried the remote drive detection code with both mapped drive paths and UNC paths by the way.
Comment 5 Brian R. Bondy [:bbondy] 2012-02-03 22:31:27 PST
With the browser open for only a couple minutes by the way there were 5 other copy calls, so this should save time in general as well.
Comment 6 (dormant account) 2012-02-04 05:15:37 PST
Brian see 716174.
Comment 7 Brian R. Bondy [:bbondy] 2012-02-04 05:51:09 PST
Taras see Comment 2 :P
Comment 8 Jim Mathies [:jimm] 2012-02-06 07:27:09 PST
Comment on attachment 594370 [details] [diff] [review]
Patch v1.

Review of attachment 594370 [details] [diff] [review]:
-----------------------------------------------------------------

Nice little bit of optimization - thanks!
Comment 9 Brian R. Bondy [:bbondy] 2012-02-06 07:45:09 PST
Thanks for the review! Pushed to try:
https://tbpl.mozilla.org/?tree=Try&rev=6909a52f8357
Comment 11 Ed Morley [:emorley] 2012-02-07 12:14:20 PST
https://hg.mozilla.org/mozilla-central/rev/ef532db5b8be

Note You need to log in before you can comment on or make changes to this bug.