454254 - dhtml benchmark on trunk 2.5x slower than latest webkit r36247

Status: NEW

(Core :: Layout, defect)

Description

[Oleg Romashin (:romaxa)]

URL running on latest central show only "dot count: 10"

The same test with webkit reference browser has "dot count: 20" (sometime 25)

I'm not sure is it right component for this bug...

Also with this test gecko a bit slower than webkit.
http://wd-testnet.world-direct.at/mozilla/dhtml/funo/dhtmltest1to10ms.htm
3900 - webkit
4500 - gecko

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can you do some profiling of the dot testcase?

Comment 2

[Oleg Romashin (:romaxa)]

Attachment: dhtml arm N810, 20 counts ~7-9 fps

Cpu usage:
89.4%  TestGtkEmbed
6.6%   Xomap

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Ugh; useful profile, but we really need to figure out a way to do callgraph profiling -- that flat profile doesn't really help us figure out what the large chunks are that are going on.  This might be reproducible on a desktop linux machine, where it could be run with Xfbdev or Xvfb, which should have similar perf characteristics as Xomap.

Comment 4

[Oleg Romashin (:romaxa)]

I don't think that Xomap very big problem for this testcase.... because on windows, and linux desktop it is also slower than webkit nightly build...

Should we use jprof for it?
I can also generate cycle profile with oprofile.

Comment 5

[Oleg Romashin (:romaxa)]

I have removed all drawing and it still slow:
-li.appendChild(document.createTextNode('\u25cf'));
+li.appendChild(document.createTextNode(''));

10 dots - mozilla
30 dots - webkit

Seems problem not in Xomap at all,

Comment 6

[Boris Zbarsky [:bzbarsky]]

If you can do a jprof, that would be great.  I just did a shark profile on Mac, and there seem to be no obvious unknown hotspots: JS execution (no jit across DOM yet), reflow, painting, style reresolution, CSS top/left setting.  I'm curious to see what your jprof will show.

Comment 7

[Guilherme Lima]

I'm on Windows XP.
Just tested the benchmark in the URL field.
When dot count is 10:

Latest build (Gecko/20110113 Firefox/4.0b10pre) - D3D9 ON ~ 50fps
Latest build (Gecko/20110113 Firefox/4.0b10pre) - D3D9 OFF ~ 40fps
Google Chrome 8.0.552.237 ~ 38fps
IE8 ~ 61fps

I have a FX5500 card. Don't know if it matters.

Comment 8

[Guilherme Lima]

I don't know when it happened, but Firefox now (latest Nightly) is waaaaaaaaay faster. 180+ fps! This bug can be closed.

Comment 9

[Boris Zbarsky [:bzbarsky]]

The frame rate at 10 dots is basically bogus on modern hardware; it's just measuring your timer clamp, not anything related to performance.

The interesting number with this test is how many dots it takes before you bottom out at 25fps...  For me, Chrome dev gets to well over 2x the number of dots we get to.

So I think this bug is alive and well.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: The testcase so it won't get lost

Comment 11

[Boris Zbarsky [:bzbarsky]]

I just redid a profile...

  40% of the time is painting, 2/3 of it text painting (all those balls are
      U+25CF characters).  Lots of textrun rebuilding for some reason.
  12% Setting inline style.
   4% JS execution
  12% reflow.  2/3 of this time is invalidation.
  28% restyling

Under restyling, 25% (so almost all of the restyle time) is ReResolveStyleContext, breaking down as:

  10% CalcStyleDifference computing all sorts of style structs on the new
      context
   3% style context allocation (largely the GetStyleDisplay in
      ApplyStyleFixups).
   3% actual rule matching
   4% ~nsStyleContext (half is ruletree gc, and the rest is deallocation and
      the like)
   
then a long tail.

Comment 12

[Guilherme Lima]

DLBI or something else regressed this benchmark. Firefox 17 gets 25fps with 285 dots. Nightly (20121023) hits 25fps with only 165 dots.
I'm on Win7 with d2d and d3d10. (Intel HD3000)

Comment 13

[Emanuel Hoogeveen [:ehoogeveen]]

This benchmark was recently brought up in http://forums.mozillazine.org/viewtopic.php?f=23&t=2775635 (though using the URL http://opera.r3m.co/tests/dhtml/test1.html, it seems to be the same test). Firefox Nightly (~50fps for 200 balls) does much worse on this test than Chrome Canary (170fps for or Internet Explorer 11. It's been a long time since this was last profiled, so how are things looking here now?

Comment 14

[Emanuel Hoogeveen [:ehoogeveen]]

Hmm, I posted an unfinished version of my comment. The second part was supposed to be:

Firefox Nightly (~50fps for 200 balls) does much worse on this test than Chrome Canary (~170fps for 200 balls) or Internet Explorer 11 (~170fps for 200 balls). It's been a long time since this was last profiled, so how are things looking here now? FWIW, I tested on 64-bit Windows 7 with 32-bit Firefox, with D2D HWA enabled.

Comment 15

[Boris Zbarsky [:bzbarsky]]

I can't tell you what it looks like on Windows, but I expect graphics to be a good part of it, because on Mac I see us ending up at 70fps for 200 balls and on the same hardware Chrome is at only 100fps for 200 balls.  So either Chrome is slower than on Windows or we're faster or both.

With that caveat, the profile on Mac looks like this:

* A bunch of time on the compositor thread (nearly half the CPU time).  Not sure whether the main thread ends up blocking on the compositor here.  Most of this is ContentHostIncremental::Composite, drawing quads and the like.

If I focus on the main thread, I see:

  15% setting inline style
  43% painting (10% painting text, lots of layer building, etc, etc).
  36% restyle processing.  

Pretty similar to comment 11, in fact.

Comment 16

[Elbart]

Current dot-count for 25fps, done on a Intel Core i5 ULV:

Nightly 2014-04-14: 50
Nightly 2014-04-14 OMTC on: 50
Nightly 2014-04-14 e10s: ~60
IE11: ~150
Chrome 34: ~300

Comment 17

[Emilio Cobos Álvarez (:emilio)]

Is this still valid? Nightly seems faster than Chromium (Linux) in this test-case on my machine (with WR enabled and such though).