Open Bug 1124325 Opened 9 years ago Updated 2 years ago

simple colorflashing benchmark causes many wakeups

Categories

(Core :: Layout, defect)

All
macOS
defect

Tracking

()

REOPENED

People

(Reporter: froydnj, Unassigned)

Details

(Keywords: perf, power, Whiteboard: [Power:P3])

Attachments

(1 file)

I was talking a bit with BenWa on #perf, and he suggested writing a simple benchmark that paints backgrounds between two alternating colors to get an idea of how we measure up compared to other browsers.

The benchmark is here:

http://people.mozilla.org/~nfroyd/power-test-pages/colorflash.html

On my Mac mini, I see the number of wakeups (measured in powermetrics(1) and Activity Monitor) increase substantially while the test is running; Activity Monitor tells me the number of idle wakeups varies from ~700 to ~2000, tending more towards the higher half of that range.

Safari, by contrast, holds steady at ~60 wakeups as measured by Activity Monitor.

dtrace tells me the wakeups are attributable to some combination of scheduling timers, making sure the main thread's native event loop is woken up, and doing IPC messaging.

BenWa said (before disappearing for a while) that he wasn't seeing the same sort of increase in wakeups, so it's possible that there's something peculiar going on with the Mac mini.
Attached file dtrace-stacks.txt
BenWa said it was useful to see the stacks from a dtrace profile, so, voilá.
BenWa pointed out that the button on the page to start and stop the test was causing the creation of unnecessary layers.  If we remove the button, we go down to ~120 wakeups (per second, I think), which is about what one would expect.

So an interesting question to ask here is, why does the button (and its associated layer?) make things so much more expensive?
(In reply to Nathan Froyd [:froydnj] [:nfroyd] from comment #2)
> BenWa pointed out that the button on the page to start and stop the test was
> causing the creation of unnecessary layers.  If we remove the button, we go
> down to ~120 wakeups (per second, I think), which is about what one would
> expect.

The no-button benchmark is at http://people.mozilla.org/~nfroyd/power-test-pages/colorflash-no-button.html
Whiteboard: [Power]
This is an entirely synthetic benchmark; it's not even a cut down version of a real website. Therefore I think it has little value, and I suggest we close this bug. froydnj, ok with you?
Flags: needinfo?(nfroyd)
(In reply to Nicholas Nethercote [:njn] from comment #4)
> This is an entirely synthetic benchmark; it's not even a cut down version of
> a real website. Therefore I think it has little value, and I suggest we
> close this bug. froydnj, ok with you?

*shrug*  Sure.
Flags: needinfo?(nfroyd)
Ok, thanks.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Actually, let's wait for the outcome of the first Project Candle triage thread.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(In reply to Nicholas Nethercote [:njn] from comment #7)
> Actually, let's wait for the outcome of the first Project Candle triage
> thread.

Then again, this bug isn't going to be included in the first set of bugs to be triaged. So I will close. Sorry for the noise.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → INCOMPLETE
I disagree here. While this benchmark is very much synthetic, it has a LOT of value in measuring our overhead when compositing at a high frame rate. This should be hitting fast GFX paths and be our best case scenario for running at 60 FPS. This benchmark could instead use Off-main-thread-animation if we wanted, it would still measure the same thing and might feel less synthetic. I notice that any site that has ongoing CSS animations, even offscreen, makes my laptop very hot.

This synthetic benchmark is most useful when comparing against what other browsers are doing. If they're beating us at this test case then likely they're going to be beating us at nearly anything that's frame rate driven.

Keep in mind I expect IE on windows and Safari on OSX to beat us with quite a lot of head way because, being native browsers using the optimal presentation API, they will have lower overhead to composite.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Whiteboard: [Power] → [Power:P3]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: