1495208 - Some IE Test drive demos are throttled, unless I start the profiler

Status: RESOLVED WONTFIX

(Core :: Gecko Profiler, defect)

Description

[Mayank Bansal]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0
Build ID: 20180929100556

Steps to reproduce:

1.create new profile
2. Go to https://testdrive-archive.azurewebsites.net/Performance/FishIETank/Default.html

3. The demo runs at 35-40fps
4. Now install the gecko profiler addon
5. Start the profiler


Actual results:

fps becomes 60fps!


Expected results:

60fps without the profiler

Comment 1

[Mayank Bansal]

The CPU is not saturated. So this is a throttling of some sort I believe.

Comment 2

[Mayank Bansal]

Also happens here : https://testdrive-archive.azurewebsites.net/Graphics/VideoPanorama/Default.html

if i use the demo normally, i get 40fps. The moment i start the profiler, i get 60fps!

Comment 3

[Mark]

(In reply to Mayank Bansal from comment #0)

> 1.create new profile
> 2. Go to https://testdrive-archive.azurewebsites.net/Performance/FishIETank/Default.html
> 3. The demo runs at 35-40fps
> 4. Now install the gecko profiler addon
> 5. Start the profiler
> 

Reproduced here. My system/numbers:

Windows 10 64-bit, Intel Core i5-7400 CPU (4 cores), Intel HD Graphics 630, using Firefox Nightly 64.0a1 (2018-09-29) (64-bit) Build-ID 20180929220033 (tested after the second Nightly update today).

New Profile, or using that New Profile with the Gecko Profiler installed: running 32-34 FPS with 20 fish. Starting Gecko Profiler and it's 60 FPS; stopping the Gecko Profiler and it is back to 32-34 FPS.

It seems odd to me that just starting the Gecko Profiler would almost double the frames that can be rendered per second.

I am attaching my about:support raw data as Mark12547_About_Support_Bug_1495208.txt

If there is any additional data I can supply in tracking this down, please let me know.

Thank you!

Comment 4

[Mark]

Attachment: Mark12547_About_Support_Bug_1495208.txt

about:support raw data.

Comment 5

[Mark]

I tried running a regression, but I got similar results (typically 37-43 FPS without Gecko Profiler running, 59 FPS with Gecko Profiler running, and back to around 34-37 FPS after stopping Gecko Profiler), and that is going back to 2017-09-30 (58.0a1). I didn't try earlier than a year ago.

Comment 6

[Fanolian]

On my machine with WebRender enabled, FPS increases from ~32 to ~50fps when I simply move the cursor inside Nightly's content area. CPU and GPU usage never exceed 30%, 20 or 1000 fish.

Computer spec:
Intel i7-4771 (8 cores)
Nvidia GTX760 with latest driver
Windows 10 1803
Current Nightly with new profile (WR enabled)

Comment 7

[Julien Wajsberg [:julienw]]

I don't reproduce on Linux with Nightly. On the fish demo I get various fps results for the "250 fishes" option (with fewer fishes it's consistently at 60fps) with or without gecko profiler.

Comment 8

[anleck]

Reminds me of this - https://bugzilla.mozilla.org/show_bug.cgi?id=1378149
Also noticed cursor activity in content area, as per comment-16

Comment 9

[Jules A]

Can't reproduce, 60fps on 1000 fish with FX8320 and RX470.

Comment 10

[Mark]

(In reply to Fanolian from comment #6)
> On my machine with WebRender enabled, FPS increases from ~32 to ~50fps when
> I simply move the cursor inside Nightly's content area. CPU and GPU usage
> never exceed 30%, 20 or 1000 fish.

I double-checked my system this morning. Still at 20 fish:

Cursor not moving, Profiler stopped: 32 FPS, 6% CPU

Cursor moving in content area, Profiler stopped: 46 FPS, 12% CPU

Cursor not moving, Profiler started: 60 FPS, 16% CPU

Repeating the exercise for 250 fish produce same frame rates at a slightly higher CPU rate (7%, 13%, 19%)

Bug 1378149 Comment 28 mentioned "an artifact of setInterval() scheduling" as causing an oddity in results for one of the benchmark sites. I wonder if we are seeing a similar effect here. It wouldn't surprise me if, for example, certain timers are purposely kept course to minimize certain exploits but are switched to fine for profiling purposes.

Comment 11

[Markus Stange [:mstange]]

Can you check if there's a specific sampling interval at which this phenomenon starts? For example, I'm interested if the case "Gecko Profiler on with interval set to 20ms" also gives 60fps performance or if the speedup only starts at 10ms and under.

One thing that comes to mind is the fact that the Gecko profiler enables "high-frequency timers" on Windows for intervals <= 10ms: https://searchfox.org/mozilla-central/rev/819cd31a93fd50b7167979607371878c4d6f18e8/tools/profiler/core/platform-win32.cpp#210-215
This reduces unnecessary waiting but increases power usage.

Furthermore, the FishIETank demo should really be using requestAnimationFrame (which is triggered by vsync), but it is using setInterval, which is subject to Windows timer accuracy.

Comment 12

[Mayank Bansal]

(In reply to Markus Stange [:mstange] from comment #11)
> Can you check if there's a specific sampling interval at which this
> phenomenon starts? For example, I'm interested if the case "Gecko Profiler
> on with interval set to 20ms" also gives 60fps performance or if the speedup
> only starts at 10ms and under.
> 
> One thing that comes to mind is the fact that the Gecko profiler enables
> "high-frequency timers" on Windows for intervals <= 10ms:
> https://searchfox.org/mozilla-central/rev/
> 819cd31a93fd50b7167979607371878c4d6f18e8/tools/profiler/core/platform-win32.
> cpp#210-215
> This reduces unnecessary waiting but increases power usage.
> 
> Furthermore, the FishIETank demo should really be using
> requestAnimationFrame (which is triggered by vsync), but it is using
> setInterval, which is subject to Windows timer accuracy.

100ms : throttled
50ms: throttled
20ms: throttled
10ms : throttled
9ms: 55fps
8ms: 55fps
6ms: 55fps
4ms: 56-58fps
2ms: 60fps
1ms: 60fps

throttled means 35-45 fps

Comment 13

[Markus Stange [:mstange]]

That's interesting. So I think what this means is just that setInterval timer scheduling is influenced by the Windows timer accuracy... which isn't all that surprising, actually. Anyway, we don't want to use high-resolution timers all the time, and the "correct" way to get 60fps JavaScript callbacks is to use requestAnimationFrame instead of setInterval, which would use V-Sync instead of timers, and for accurate vsync we don't need high resolution timers.
So I don't know if there's anything we want to do here.

Comment 14

[Mayank Bansal]

(In reply to Markus Stange [:mstange] from comment #13)
> So I don't know if there's anything we want to do here.

closing this bug as WONTFIX