1423369 - MotionMark CSS bouncing circles spends a significant portion of time on the style system

Status: REOPENED

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Jeff Muizelaar [:jrmuizel]]

https://perfht.ml/2nw1jvt

This is running http://browserbench.org/MotionMark/developer.html?test-interval=30&display=minimal&tiles=big&controller=ramp&frame-rate=50&kalman-process-error=1&kalman-measurement-error=4&time-measurement=performance&suite-name=HTMLsuite&test-name=CSSbouncingcircles&complexity=143

with gfx.webrender.hit-test=true

Comment 1

[Emilio Cobos Álvarez (:emilio)]

No add-ons? The fact that the invalidation code appears there reminds me of the same bug report from Markus... And I can't repro (style is ~5% of the time, vs 40% painting) on my machine.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

uBlock strikes again. sorry.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Can you file a bug against uBlock about the performance regression that it's causing?

Comment 4

[Jeff Muizelaar [:jrmuizel]]

So here's a profile without uBlock. Style doesn't dominate but it's still a significant portion
https://perfht.ml/2ipIepD

Comment 5

[Emilio Cobos Álvarez (:emilio)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #4)
> So here's a profile without uBlock. Style doesn't dominate but it's still a
> significant portion
> https://perfht.ml/2ipIepD

That profile didn't have much resolution, I took one with a smaller sampling interval (https://perfht.ml/2inqo6x).

Style takes about 2% of that, though note this is with WR disabled because of bug 1418212 :/.

There's some functions there which could be smarter, like the transform cascade stuff...

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #3)
> Can you file a bug against uBlock about the performance regression that it's
> causing?

(See bug 1418161 comment 8 for the uBlock Origin developer's thoughts on this.)

Comment 7

[[e-mail]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #1)
> And I can't repro (style is ~5% of the time, vs 40% painting) on my machine.

I found a way to systematically get bad results on my side, regardless of whether uBlock is installed or not.

Repro steps:

1. Create a bookmark on the toolbar out of the browserbench.org link in comment #0, name it "MotionMark" (for convenience in repro-ing)

Good result scenario:

1. Launch Firefox 57.0.4, no extension.
2. Open new tab.
3. Click the browserbench.org link in the toolbar.
4. The benchmark runs its course, appears normal.
5. Result: ~126 -- with or without uBlock.

Bad result scenario:

1. Launch Firefox 57.0.4, no extension.
2. Open new tab.
3. Drag the browserbench.org link in the toolbar aside the existing tab, such that a new tab is created out of it.
4. Important: the new browserbench.org page is not yet visible.
5. Wait 5 seconds after the (still not visible) page finishes loading.
6. Activate the browserbench.org page to make its content visible.
7. The benchmark runs its course, but very few bouncing circles are seen.
8. Result: ~8 -- with or without uBlock.

So it seems the benchmark was in a pathological state in the bad-result scenario. I wonder if this is what was observed originally here, maybe there are other ways to trigger the pathological state.

I could not reproduce the pathological case with Chromium 63 with above STR.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

(In reply to [e-mail] from comment #7)
> (In reply to Emilio Cobos Álvarez [:emilio] from comment #1)
> > And I can't repro (style is ~5% of the time, vs 40% painting) on my machine.
> 
> I found a way to systematically get bad results on my side, regardless of
> whether uBlock is installed or not.
> 
> Repro steps:
> 
> 1. Create a bookmark on the toolbar out of the browserbench.org link in
> comment #0, name it "MotionMark" (for convenience in repro-ing)
> 
> Good result scenario:
> 
> 1. Launch Firefox 57.0.4, no extension.
> 2. Open new tab.
> 3. Click the browserbench.org link in the toolbar.
> 4. The benchmark runs its course, appears normal.
> 5. Result: ~126 -- with or without uBlock.
> 
> Bad result scenario:
> 
> 1. Launch Firefox 57.0.4, no extension.
> 2. Open new tab.
> 3. Drag the browserbench.org link in the toolbar aside the existing tab,
> such that a new tab is created out of it.
> 4. Important: the new browserbench.org page is not yet visible.
> 5. Wait 5 seconds after the (still not visible) page finishes loading.
> 6. Activate the browserbench.org page to make its content visible.
> 7. The benchmark runs its course, but very few bouncing circles are seen.
> 8. Result: ~8 -- with or without uBlock.
> 
> So it seems the benchmark was in a pathological state in the bad-result
> scenario. I wonder if this is what was observed originally here, maybe there
> are other ways to trigger the pathological state.
> 
> I could not reproduce the pathological case with Chromium 63 with above STR.

Could you take a profile of that without uBlock? (see https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler)

Comment 9

[[e-mail]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #8)
> Could you take a profile of that without uBlock? (see
> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/
> Profiling_with_the_Built-in_Profiler)

https://perfht.ml/2F6ObBh

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Ok, so that profile seems to have broken symbols, but I could repro the STRs in comment 7, and on my local profile looks like we're not spending CPU time basically anywhere... So I suspect this is a completely different issue (failing to un-throttle inactive tabs or something?).

Farre, maybe you're interesting in taking a look at this?

Comment 11

[Emilio Cobos Álvarez (:emilio)]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #10)
> Ok, so that profile seems to have broken symbols, but I could repro the STRs
> in comment 7, and on my local profile looks like we're not spending CPU time
> basically anywhere... So I suspect this is a completely different issue
> (failing to un-throttle inactive tabs or something?).
> 
> Farre, maybe you're interesting in taking a look at this?

FWIW, the relevant code is this one:

  https://searchfox.org/mozilla-central/rev/b7e3ec2468d42fa59d86c03ec7afeb209813f1d4/third_party/webkit/PerformanceTests/MotionMark/tests/resources/main.js#915

Which seems a normal requestAnimationFrame loop. I'm not sure if there's something fishy there with the warmup stuff related to our timer throttling, but there shouldn't.

In any case, if it's worth looking into it further probably deserves another bug instead of this one.

Comment 12

[Andreas Farre [:farre]]

I tried turning off budget throttling by setting dom.timeout.enable_budget_timer_throttling to false. This does nothing to improve the situation (and it really shouldn't, budget throttling doesn't kick until after 30s after page load).

Setting dom.min_background_timeout_value to 4, which is the default min value of regular timeout improves the situation somewhat, but not really that much.

Here's the thing though, I tried it in Chrome, and it's a bit trickier to reproduce, but just open the link from comment #0 and as quick as possible switch to another tab. Wait a while and switch back and you'll see the same bad behaviour in Chrome.

I haven't studied the test in detail, but I'd guess that they're using rAF to gauge how many samples (balls) that they should animate, and both we and Chrome run rAF callbacks way less than on 60 fps while a tab is in the background.

So, probably not that related to throttling, except the throttling of rAF, which we share with other browsers.