1349801 - Support sub-millisecond profiling intervals on Windows

Status: RESOLVED FIXED

(Core :: Gecko Profiler, enhancement)

Description

[Markus Stange [:mstange]]

Profiles collected on Windows usually have an effective sampling interval of about 2ms. We should find out whether it's possible to reduce this.

The Windows Sleep function only accepts integer milliseconds. It looks like creating an accurate SleepMicro function is a bit of work: http://stackoverflow.com/a/11470617

We should also check how much time it takes to walk the stack. Maybe inaccurate sleeps aren't even the problem.

If we request a Sleep(1) and end up sleeping longer than 1ms, we should check whether it helps to supply lower numbers to timeBeginPeriod / timeEndPeriod.

Bug 1344169 will make us try to dynamically adjust the sleep length on Windows, but I doubt it's going to help as long as we can't sleep less than 1ms.

Comment 1

[(Away)]

I was going to suggest that we warn if timeBeginPeriod fails, but on my machine, timeBeginPeriod(1) returns TIMERR_NOERROR even though I can't capture samples that fast.

Comment 2

[Markus Stange [:mstange]]

(In reply to Markus Stange [:mstange] from comment #0)
> If we request a Sleep(1) and end up sleeping longer than 1ms, we should
> check whether it helps to supply lower numbers to timeBeginPeriod /
> timeEndPeriod.

Oh, timeBeginPeriod only accepts integer milliseconds. So going below 1 isn't even an option.

Comment 4

[Markus Stange [:mstange]]

David, would you like to investigate this some more? It might be worth using a busy-loop just as an experiment and seeing whether that even yields useful data. (Apparently there's a "pause" instruction that makes busy loops not waste as much CPU as it usually would, that seems worth trying out.)

Comment 5

[(Away)]

Ok, I'll try to play around with it if/when I have a chance.

Comment 6

[(Away)]

This is on my list to look at, currently behind profiler crash/hang fixes.

Comment 7

[(Away)]

I tried using SetWaitableTimer which claims to have 100ns resolution, but it always returned immediately for me. Maybe there is some implicit minimum. I guess "pause" is the best we can do. :(

Comment 8

[(Away)]

Attachment: Make SleepMicro a method of SamplerThread

Comment 9

[(Away)]

Attachment: Make aMicroseconds unsigned to avoid some checks

Comment 10

[(Away)]

Attachment: Use 'pause' for sub-msec spins on Windows

Because this is going to devour one core per Firefox process, I'm not comfortable unleashing it on the whole world. I've made it so that we don't use this code, not even for overshoots, unless your sampling interval is explicitly <1ms. (And checking that variable is why I made SleepMicro a method of SamplerThread.)

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0aae6f865e8d
Make SleepMicro a method of SamplerThread. r=mstange
https://hg.mozilla.org/integration/mozilla-inbound/rev/cde48b1034b6
Make aMicroseconds unsigned to avoid a bunch of checks. r=mstange
https://hg.mozilla.org/integration/mozilla-inbound/rev/fdfb138fa1a1
Allow sub-millisecond profiler intervals with a busy wait on Windows. r=mstange

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/0aae6f865e8d
https://hg.mozilla.org/mozilla-central/rev/cde48b1034b6
https://hg.mozilla.org/mozilla-central/rev/fdfb138fa1a1