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
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: Trunk
: All Windows 7
-- normal (vote)
: mozilla13
Assigned To: Brian R. Bondy [:bbondy]
: Nathan Froyd [:froydnj]
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:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

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 User image 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 User image Brian R. Bondy [:bbondy] 2012-02-03 17:10:53 PST
Created attachment 594370 [details] [diff] [review]
Patch v1.
Comment 2 User image Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-02-03 17:35:32 PST
See also Bug 716174.
Comment 3 User image 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 User image 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 User image 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 User image (dormant account) 2012-02-04 05:15:37 PST
Brian see 716174.
Comment 7 User image Brian R. Bondy [:bbondy] 2012-02-04 05:51:09 PST
Taras see Comment 2 :P
Comment 8 User image 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 User image Brian R. Bondy [:bbondy] 2012-02-06 07:45:09 PST
Thanks for the review! Pushed to try:
Comment 11 User image Ed Morley [:emorley] 2012-02-07 12:14:20 PST

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