Last Comment Bug 722225 - Improve Firefox startup speed by ~5% (-70ms) on Windows by optimizing D3D10CreateDevice1
: Improve Firefox startup speed by ~5% (-70ms) on Windows by optimizing D3D10Cr...
Status: RESOLVED FIXED
[gfx.relnote.13]
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: unspecified
: x86_64 Windows 7
: -- normal (vote)
: mozilla13
Assigned To: Brian R. Bondy [:bbondy]
:
: Milan Sreckovic [:milan]
Mentors:
Depends on:
Blocks: 725508
  Show dependency treegraph
 
Reported: 2012-01-29 21:24 PST by Brian R. Bondy [:bbondy]
Modified: 2012-05-24 11:38 PDT (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch v1. (5.29 KB, patch)
2012-01-29 21:24 PST, Brian R. Bondy [:bbondy]
bas: review+
Details | Diff | Splinter Review
Patch v2. (5.84 KB, patch)
2012-02-08 20:48 PST, Brian R. Bondy [:bbondy]
netzen: review+
Details | Diff | Splinter Review

Description Brian R. Bondy [:bbondy] 2012-01-29 21:24:11 PST
Created attachment 592603 [details] [diff] [review]
Patch v1.

While profiling imagelib, I noticed that GIF loading takes over 100ms at Firefox startup.

The 11 GIFs take over 114ms compared to all other images take only 20ms to load.
In particular I noticed that only 1 of the GIF images took almost the whole 114ms. 
On closer inspection, it didn't matter which GIF, just the first one to load causes the 114ms load time.

Here's the profiling results in question:

> NAME: mozilla::image::nsGIFDecoder2::WriteInternal 
> Count: 11
> Total: 0.114:04 
> Min: 0.000:00 
> Max: 0.114:04
> Average: 0.010:36
> App start time until first paint: 0.914:00

After digging deeper I found that almost the entire 114ms was taken from gfxWindowsPlatform::VerifyD2DDevice(),
and in particular the calls to createD3DDevice.

I found that we can take the 114ms above down to ~30ms with the following patch.
What we do that causes the slowdown is first query for a D3D 10.0 device, followed by query a 10.1 if the 10.0 succeeded.
Instead if we detect we can get the 10.1 we should try that first, then fall back to 10.0.
So only the first load will ever be as slow as it used to be.
For some reason querying both 10.0 and 10.1 takes significantly longer than half the time from just querying one.

For a hot startup (not directly after a reboot) I have a startup time of average 912ms (until first paint) and a saving of average 62ms. 
So from testing I've seen between 3-10% speedups on startup for hot Firefox startup, I haven't tried with cold boots+startup but I suspect it won't be as significant.
Comment 1 Brian R. Bondy [:bbondy] 2012-01-29 21:29:58 PST
I should mention my prefetch is also disabled via the other patch, so all numbers above are without prefetch.  The speed gains from not having prefetch is not related to this patch though.
Comment 2 Joe Drew (not getting mail) 2012-01-30 10:06:19 PST
Comment on attachment 592603 [details] [diff] [review]
Patch v1.

Bas wrote this code, and he, I presume, had a reason for trying 10.0 first.
Comment 3 Brian R. Bondy [:bbondy] 2012-01-30 10:08:18 PST
It still tries 10.0 first, but after it knows that 10.1 is avail it will try 10.1 first.  If 10.1 becomes unavail it reverts back to 10.0 first.
Comment 4 Bas Schouten (:bas.schouten) 2012-02-08 17:55:06 PST
Comment on attachment 592603 [details] [diff] [review]
Patch v1.

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

::: gfx/thebes/gfxWindowsPlatform.cpp
@@ +359,5 @@
> +        // a createD3DDevice on D3D10_FEATURE_LEVEL_10_0 and 
> +        // D3D10_FEATURE_LEVEL_10_1.  Therefore we set a pref if we ever get
> +        // 10.1 to work and we use that first if the pref is set.
> +        // Going direct to a 10.1 check only takes 20-30ms.
> +        HRESULT hr = E_FAIL;

A little documentation around the logic surrounding this initialization and how it affects the rest of the flow would be nice :).
Comment 5 Brian R. Bondy [:bbondy] 2012-02-08 20:48:58 PST
Created attachment 595627 [details] [diff] [review]
Patch v2.

Thanks for the review!

Updated patch with the initialization explained in the comment.  Carrying forward r+.  Pushed to try, and I will push to inbound once that passes tomorrow.
Comment 6 Brian R. Bondy [:bbondy] 2012-02-09 10:51:39 PST
http://hg.mozilla.org/integration/mozilla-inbound/rev/ffad3415e91e
Comment 7 Ed Morley [:emorley] 2012-02-10 05:05:00 PST
https://hg.mozilla.org/mozilla-central/rev/ffad3415e91e

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