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.

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

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

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

Martijn, can you hunt down the regression range?

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

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

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.

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

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.

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

(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.

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

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

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

(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.

(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.

Regression found... Firefox 10.0a1 20110930: 8054 Firefox 10.0a1 20110929: 3822 Please let me know if there is more I can do.

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

(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

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

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.

(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

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.

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

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.

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.

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

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.

> 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?

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.