691645 - IE Maze solver painting is slow

Status: NEW

(Core :: Web Painting, defect)

Description

[Boris Zbarsky [:bzbarsky]]

I tried working around bug 641340 by simply sticking "-moz-transform: translate(0,0)" in the rule for .marker using DOM Inspector.

If I do that, we're still slow, but now it's all painting (building display lists and the actual painting we do).  I wonder why we end up invalidating more than just the markers that actually get moved...  I tried turning off hardware acceleration and using the Quartz Debug paint flashing, and the whole maze flashes a good bit.

Comment 1

[Boris Zbarsky [:bzbarsky]]

It's possible that we're still doing some reflow here (see bug 524925).  Odd that I did not see it in my profile....

Comment 2

[Timothy Nikkel (:tnikkel)]

The MazeContainer is float: left so if we reflow anything inside it we will invalidate the whole maze because of this code http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsBlockFrame.cpp#2505 , no?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Could be, yes.  Hence the dependency.

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

This test is repeatedly being used as a benchmark in editions of Tom's Hardware's  "Web Browser Grand Prix" so it's worth having a closer look at. Profile data coming.

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: raw data from 'perf' (you need perf to use that)

Uncompress with xz -d, and run `perf report` in the same directory.

If you don't have perf / are not on Linux, plain text files are coming.

Comment 6

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: profile call graph, as plain text (xz compressed)

Just uncompress with xz -d, this is a plain text file.

Comment 7

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: flat profile, just plain text (for the lazy!)

Use that if you can't be bothered to use xz -d ;-)

Comment 8

[Benoit Jacob [:bjacob] (mostly away)]

Has anyone had time to look at the profiles?
We've been hit again by this bug in this new Browser Grand Prix:
http://www.tomshardware.com/reviews/windows-xp-web-browser-performance,3167-8.html

Comment 9

[Timothy Nikkel (:tnikkel)]

There has been work on this, but it happened off of bug 641341. Specifically bug 730769 and bug 730771. The bugs show that Mats has done some of his own profiling, and bz has profiled this before too.

Comment 10

[Boris Zbarsky [:bzbarsky]]

What comment 9 said.  But more importantly, we've been hit by this _testcase_.  There are a number of separate performance issues here (see also the bug linked in comment 0), which we're working on fixing one by one.  This bug is about the painting parts specifically.  It's possible that bug 539356 will more or less ameliorate it.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Oh, and maybe we do just need a single tracker bug for this testcase....

Comment 12

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

The worst of the over-invalidation is because of this code in nsFrame::InvalidateInternalAfterResize:
    nsRect newDamageRect = nsDisplayTransform::TransformRectOut
                             (aDamageRect, this, nsPoint(-aX, -aY));
    if (!(GetStateBits() & NS_FRAME_SVG_LAYOUT)) {
      newDamageRect.UnionRect(newDamageRect, aDamageRect);
    }
Basically, because callers of Invalidate are confused about whether the incoming rect is before applying transforms or after applying transforms, we're super-conservative here and assume it could be either. We can improve this, but DLBI will fix it too, so I think we should just focus on finishing DLBI.

Comment 13

[IU]

DLBI, as landed today (cset 75cdb3f932c6), only marginally fixes this.

On my WinXP system, Firefox takes 49 seconds, whereas Chrome takes 6.1 seconds.

Comment 14

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

DBLI has definitely not landed today. Only some parts landed, and not the parts that help with this bug.

Comment 15

[Dennis Jakobsen]

I'm now seeing 7,4 seconds on Nightly, excellent progress!

Comment 16

[Mayank Bansal]

i am seeing much better performance now on a 40x40 maze. Excellent work!

Comment 17

[Dennis Jakobsen]

I'm seeing a consistent 6 second run on 40x40 even with paintflashing on. DLBI is still over-invalidating in the 40x40 maze, but i'll report that in dlbi.

Comment 18

[Pascal Chevrel:pascalc (PTO until April 26)]

I am noticing something interesting with this perf testcase and its interaction with Flash and Facebook, it may be another bug affecting the overall performance of this specific test though, just tell me if I need to open a separate bug.

Here is what I am seeing: 
- if I only have the IE Maze page open in Nightly on Linux, I get results around 12 seconds for the 30x30 maze
- if I also have a facebook tab open + flash activated, the same 30x30 maze is 112 second
- if I disable Flash in about:plugins, I get results around 12s with or without a Facebook tab open
- If I activate Flash, have a flash video on youtube in a tab running, no facebook page open and run the IE maze, I get about 14s

That makes:

It seems that Facebook is using Flash in ways that impact painting a lot in the IE maze tab.

Comment 19

[Timothy Nikkel (:tnikkel)]

Are you testing with a nightly that has bug 642257 (so 2012-10-19 or newer)?

Comment 20

[Pascal Chevrel:pascalc (PTO until April 26)]

I was testing with yesterday's nightly, I am going to test today's and report back.

Comment 21

[Pascal Chevrel:pascalc (PTO until April 26)]

(In reply to Timothy Nikkel (:tn) from comment #19)
> Are you testing with a nightly that has bug 642257 (so 2012-10-19 or newer)?

This is fixed with today's nightly, so that was the bug I was seeing :)

Comment 22

[Raul Nicolae Malea]

Maze 30x30 - 6 seconds with more tabs activated (including Facebook)
Maze 40x40 - 10 seconds

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121019030551

about:me 0.5
Adblock Plus 2.1.2
Add-on Compatibility Reporter 1.1
Adobe Acrobat - Create PDF 1.2
Adobe Acrobat 10.1.4.38
Adobe Acrobat 11.0.0.379
ANIMATED - Snowflake Village 1320945460 [DISABLED]
British English Dictionary 1.19.1
Bugzilla Tweaks 1.12.1
Cheevos 1.4
Collusion 0.16.3 [DISABLED]
Dicționar românesc de corectare ortografică. 1.12
Download Statusbar 0.9.10
fireblur 1260925626 [DISABLED]
Google Earth Plugin 6.2.0.5788
Google Shortcuts 2.1.7.1
Google Update 1.3.21.123
HP Smart Web Printing 4.5 [DISABLED]
Implicit 19.0a1
Java Deployment Toolkit 7.0.70.11 10.7.2.11
Java(TM) Platform SE 7 U7 10.7.2.11
Microsoft Office 2010 14.0.4730.1010
Microsoft Office 2010 14.0.4761.1000
Mozilla QA Companion 1.2.3
Mozilla Reps Companion 1.1
MozMill 1.5.19
Mozmill Crowd 0.1.5
Nightly Tester Tools 3.3
NoScript 2.5.8
NVIDIA 3D Vision 7.17.13.697
NVIDIA 3D VISION 7.17.13.697
Puppy Dogs... 1291695684 [DISABLED]
Sage 1.4.12
Shockwave Flash 11.4.402.287
Silverlight Plug-In 5.1.10411.0
Submit Word 1.1.0
Test Pilot 1.2.2
VLC Web Plugin 2.0.2.0
Yahoo Application State Plugin 1.0.0.7

Comment 23

[Chris Peterson [:cpeterson]]

This CSS3 layout benchmark is slower when Stylo is enabled. Results for solving the large 40x40 maze on my Windows 10 laptop:

Firefox 54 = 20 seconds
Firefox Nightly 56 without Stylo = 17 seconds
Firefox Nightly 56 with Stylo pref enabled = 21 seconds
Edge = 31 seconds
Chrome Beta 60 = 6.4 seconds!

Comment 24

[Bobby Holley (:bholley)]

We're still not ready for people to run performance benchmarks on stylo. We need Manish to land his stuff and do a few other things before any performance comparisons will be meaningful.

Comment 25

[Boris Zbarsky [:bzbarsky]]

Please do not hijack bugs.  This bug was about a specific issue which had nothing to do with stylo.  Please file a separate bug for whatever stylo issue you see.

Comment 26

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 10 votes.
:tnikkel, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.