Closed Bug 1454638 Opened 2 years ago Closed 2 years ago

browser.startup.blankWindow slows down the startup

Categories

(Firefox :: General, defect)

59 Branch
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1454908

People

(Reporter: xidorn, Unassigned)

References

Details

(Whiteboard: [fxperf:p1])

It seems to me that browser.startup.blankWindow actually makes the startup much slower than before.

I took a stopwatch on a Windows 7 virtual machine with a latest nightly and using the url bar as the hero element. With browser.startup.blankWindow switched off, the time between I click the icon to the url bar shows up is 1~1.5s, but when turning that on, the time of this becomes ~2.5s, which is much slower.
(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #0)
> It seems to me that browser.startup.blankWindow actually makes the startup
> much slower than before.
> 
> I took a stopwatch on a Windows 7 virtual machine with a latest nightly and
> using the url bar as the hero element. With browser.startup.blankWindow
> switched off, the time between I click the icon to the url bar shows up is
> 1~1.5s, but when turning that on, the time of this becomes ~2.5s, which is
> much slower.

Is this specific to your machine? Telemetry data doesn't seem to agree with your perception: https://mzl.la/2J46N6y

If you think something needs investigation, could you please capture startup profiles with both values of the pref so that we can compare them?
Profiles:
blankWindow switched off: https://perfht.ml/2EU2W9T
blankWindow switched on: https://perfht.ml/2EU39tH

This profile pretty much confirms my feeling. If you want I can also take a screencast, although I suspect how useful is that.

The telemetry tells nothing without a A/B testing I would argue...
It's probably not specific to that machine. I think I have similar perception on my win10 dev box.
(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #2)
> Profiles:
> blankWindow switched off: https://perfht.ml/2EU2W9T
> blankWindow switched on: https://perfht.ml/2EU39tH
> 
> This profile pretty much confirms my feeling. If you want I can also take a
> screencast, although I suspect how useful is that.
> 
> The telemetry tells nothing without a A/B testing I would argue...

In the profile with the blank window enabled, I see about 800ms spent in nsAppShell::ProcessNextNativeEvent: https://perfht.ml/2H79NP6 I wonder which events are being processed and why it takes so long.
(In reply to Florian Quèze [:florian] from comment #4)
> (In reply to Xidorn Quan [:xidorn] UTC+10 from comment #2)
> > Profiles:
> > blankWindow switched off: https://perfht.ml/2EU2W9T
> > blankWindow switched on: https://perfht.ml/2EU39tH
> > 
> > This profile pretty much confirms my feeling. If you want I can also take a
> > screencast, although I suspect how useful is that.
> > 
> > The telemetry tells nothing without a A/B testing I would argue...
> 
> In the profile with the blank window enabled, I see about 800ms spent in
> nsAppShell::ProcessNextNativeEvent: https://perfht.ml/2H79NP6 I wonder which
> events are being processed and why it takes so long.

Here is a better profile of it captured on my Windows 10 dev machine: https://perfht.ml/2qL41fl

I strongly suspect this to be a regression from bug 1450293.
Blocks: 1450293
Whiteboard: [fxperf:p1]
Jim, any idea of why we are spending so much time processing native events there?
Flags: needinfo?(jmathies)
See Also: → 1454908
I have a patch in bug 1454908.
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(jmathies)
Resolution: --- → DUPLICATE
Duplicate of bug: 1454908
You need to log in before you can comment on or make changes to this bug.