The default bug view has changed. See this FAQ.

30-50ms (5%) Firefox startup speed optimization on Windows in nsLocalFileWin

RESOLVED FIXED in mozilla13

Status

()

Core
XPCOM
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: bbondy, Assigned: bbondy)

Tracking

Trunk
mozilla13
All
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Assignee)

Description

5 years ago
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.
(Assignee)

Comment 1

5 years ago
Created attachment 594370 [details] [diff] [review]
Patch v1.
Attachment #594370 - Flags: review?(jmathies)
See also Bug 716174.
(Assignee)

Comment 3

5 years ago
Thanks for the heads up khuey, I put some info in that bug about the post effects after this lands.
(Assignee)

Comment 4

5 years ago
jimm: I tried the remote drive detection code with both mapped drive paths and UNC paths by the way.

Updated

5 years ago
Blocks: 545650
(Assignee)

Comment 5

5 years ago
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

5 years ago
Brian see 716174.
Depends on: 716174
(Assignee)

Comment 7

5 years ago
Taras see Comment 2 :P

Comment 8

5 years ago
Comment on attachment 594370 [details] [diff] [review]
Patch v1.

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

Nice little bit of optimization - thanks!
Attachment #594370 - Flags: review?(jmathies) → review+
(Assignee)

Comment 9

5 years ago
Thanks for the review! Pushed to try:
https://tbpl.mozilla.org/?tree=Try&rev=6909a52f8357
(Assignee)

Comment 10

5 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/ef532db5b8be
Target Milestone: --- → mozilla13
https://hg.mozilla.org/mozilla-central/rev/ef532db5b8be
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Hardware: x86_64 → All
Resolution: --- → FIXED
Version: unspecified → Trunk
You need to log in before you can comment on or make changes to this bug.