729597 - Performance regression in moving absolutely positioned block inside table

Status: RESOLVED DUPLICATE of bug 745485

(Core :: Layout: Positioned, defect)

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase, which comes from bug 442797, basically.

Click on the "start scrolling test" to start the test.

On Firefox 11b, I get as result:
Time it took: 12848ms

On a 2012-02-22 trunk build, I get:
Time it took: 30258ms

So something caused this to regress in performance during this time frame.

Comment 1

[Martijn Wargers (dead)]

Also seeing this performance degradation on http://people.mozilla.com/~mwargers/tests/performance/386944_speedissuecreatingtable.html

Comment 2

[Martijn Wargers (dead)]

Also seeing a performance regression on http://www.ebrahim.org/mozilla/core/bugs/243312/ (url from bug 243312).

Comment 3

[Martijn Wargers (dead)]

I suspect this is a 'slowness in painting' issue.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Martijn, can you hunt down the regression range?

Comment 5

[Timothy Nikkel (:tnikkel)]

On Linux nightly is about 8.8s and FF 10 is about 12s.

Comment 6

[Martijn Wargers (dead)]

perf regression between:
2012-01-31: http://hg.mozilla.org/mozilla-central/rev/3f26b7bee352
2012-02-01: http://hg.mozilla.org/mozilla-central/rev/e18c7bc2c28e
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-01-30+01%3A00%3A00&enddate=2012-02-01+12%3A00%3A00

Comment 7

[Martijn Wargers (dead)]

Tried tinderbox builds:
http://hg.mozilla.org/mozilla-central/rev/15b00ab7f22d - slow
http://hg.mozilla.org/mozilla-central/rev/bbc7014db2de - slow
http://hg.mozilla.org/mozilla-central/rev/1f3c7fa158aa - slow
http://hg.mozilla.org/mozilla-central/rev/63757aa2e629 - quicker 19s
http://hg.mozilla.org/mozilla-central/rev/3f26b7bee352 - quicker 19s

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-01-30+20%3A00%3A00&enddate=2012-01-31+04%3A00%3A00

3f26b7bee352 should be same as nightly build, not sure why it is slower, I guess some issue with tinderbox or nightly.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

This is unlikely to have been caused by the azure changes in that range because they should only effect canvas.

Comment 9

[Alex Keybl [:akeybl]]

Tracking for FF12 and 13 since this regression range spans the version bump on m-c. Jeff - sending over to you to continue the investigation.

Comment 10

[Timothy Nikkel (:tnikkel)]

Since I can't reproduce on Linux maybe it is one of Bas' changes in that range? Or the switch to MSVC 2010?

Comment 11

[Alex Keybl [:akeybl]]

(In reply to Timothy Nikkel (:tn) from comment #10)
> Since I can't reproduce on Linux maybe it is one of Bas' changes in that
> range? Or the switch to MSVC 2010?

Adding qawanted to confirm affected platforms.

Comment 12

[u279076]

Some comparative testing results:

Nightly: 10803, 10963, 10312, 11384, 11139
Aurora: 9377, 9378, 9417, 9449, 9416
11.0b7: 8506, 8492, 8421, 8375, 8401
11.0b6: 8008, 7965, 7915, 7892, 8020
11.0b4: 7923, 7939, 7928, 7909, 7861
11.0b2: 8813, 8419, 8248, 8385, 8228
10.0.2: 7755, 7638, 7633, 7776, 7842
9.0: 3884, 3888, 3866, 3925, 3796

Comment 13

[Timothy Nikkel (:tnikkel)]

Oh my, we keep getting worse. Looks like we have more than one regression. What platform was that Anthony?

Comment 14

[Timothy Nikkel (:tnikkel)]

We should track down the doubling in time regression between 9 and 10.

Comment 15

[u279076]

(In reply to Timothy Nikkel (:tn) from comment #13)
> Oh my, we keep getting worse. Looks like we have more than one regression.
> What platform was that Anthony?

This was run on a Windows 7 64-bit VM. 

Note that I did not go any earlier than Firefox 9. I'm not sure what a baseline/acceptable time is for this test so it's not clear to me if we can do much better than Firefox 9. Please let me know if you want results from earlier builds.

Comment 16

[u279076]

(In reply to Timothy Nikkel (:tn) from comment #14)
> We should track down the doubling in time regression between 9 and 10.

I can start by comparing releases between Firefox 9.0 and 10.0.2 if that would help.

Comment 17

[u279076]

Regression found...
Firefox 10.0a1 20110930: 8054
Firefox 10.0a1 20110929: 3822

Please let me know if there is more I can do.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Anthony, what are the changset IDs for those two builds?

Comment 19

[u279076]

(In reply to Boris Zbarsky (:bz) from comment #18)
> Anthony, what are the changset IDs for those two builds?

I'm not sure -- the mozregression tool is currently broken and I usually rely on that to return the changeset ID. 

Here is the pushlog between those two dates:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2011-09-29&enddate=2011-09-30

Comment 20

[Boris Zbarsky [:bzbarsky]]

You can just get the changeset IDs from about:buildconfig in the relevant builds.

Comment 21

[Boris Zbarsky [:bzbarsky]]

In any case, looks like a "regression" from bug 10209.  It used to be that the abs pos thing wasn't actually inside the table, so moving it didn't involve doing anything with the table at all.  But that changed in bug 10209, so now we're reflowing the table as we go...  I wonder whether we can optimize away parts of that reflow or something.

Comment 22

[u279076]

(In reply to Boris Zbarsky (:bz) from comment #20)
> You can just get the changeset IDs from about:buildconfig in the relevant
> builds.

Thanks!

Last Good: Firefox 10.0a1 2011-09-29 
Built from http://hg.mozilla.org/mozilla-central/rev/cb4b93331e4f

First Bad: Firefox 10.0a1 2011-09-30
Built from http://hg.mozilla.org/mozilla-central/rev/b5b082d183d0

Comment 23

[Alex Keybl [:akeybl]]

From comment 12, the majority of the performance regression since 9 appears to have occurred because of bug 10209. The perf difference between 10 and 11, however, is far smaller. Given that, I don't believe this needs to be tracked for 12/13.

Comment 24

[(no longer active)]

There isn't really anything in particular happening here, we just end up reflowing everything, and table reflow is expensive.  I'll dupe this.

Comment 25

[Martijn Wargers (dead)]

This bug is a regression in performance (from bug 10209 apparently), see comment 21.
Bug 157681 did exist before this regression did occur, so this can't be a duplicate.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Before bug 10209, we simply rendered the testcase incorrectly.  As a result, it did not run into the performance issues described in bug 157681.

When rendering the testcase correctly, it runs into those issues.

Comment 27

[(no longer active)]

Also, note that there are tons of other ways which can trigger similarly bad performance without using the stuff changed in bug 10209.

Comment 28

[Martijn Wargers (dead)]

With a 20120606 build I get 33596ms
With a 20120617 build I get 41098ms

So performance seems to have gone downwards with the fix for bug 157681. But perhaps the testcase is now rendering more correctly now, I don't know.

Comment 29

[Boris Zbarsky [:bzbarsky]]

> So performance seems to have gone downwards with the fix for bug 157681

Then we should look at this again.  Bug 157681 should not have affected correctness, only performance.

Ehsan, could you take a look?

Comment 30

[(no longer active)]

This test case doesn't fall into the conservative optimization performed in bug 157681.  Bug 745485 has been filed to extend this optimization to more cases, which should cover this case.