Closed Bug 494255 Opened 15 years ago Closed 7 years ago

Txul increase 9.68% on XP Firefox3.5 on 5/19/2009

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
1.9.1 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
status1.9.1 --- ?

People

(Reporter: robert.strong.bugs, Assigned: johnath)

Details

Any particular reason this is in RelEng ? Can't see any talos code changes in that time window. Perhaps Core::General and blocking1.9.1?
I used another increase as a template... moving to core -> general
Component: Release Engineering → General
Product: mozilla.org → Core
QA Contact: release → general
Version: other → 1.9.1 Branch
Flags: blocking1.9.1?
The only thing that I can think of that might be causing this from the patch in bug 492014 is if adding the solidcolor item inside a clip causes the display list optimizer to fail to remove the solidcolor item. I investigated this with a build that always adds a solidcolor item (doesn't check for null frame or suppressed paint) and in every case the solidcolor item was removed when painting a XUL document that contained a subdocument.
(In reply to comment #3)
> ... I investigated this ... and in every case ...

That makes it sound like I did some exhaustive testing. I just clicked around and tried some things.

I wanted to see if bug 492014 caused a regression in Txul when it was pushed to m-c. For reference bug 492014 was pushed to m-c 2009-05-14 20:19:26.

Looking at Txul in winxp for mozilla-central (http://graphs-new.mozilla.org/#tests=[{%22test%22:%2217%22,%22branch%22:%221%22,%22machine%22:%2255%22},{%22test%22:%2217%22,%22branch%22:%221%22,%22machine%22:%2258%22},{%22test%22:%2217%22,%22branch%22:%221%22,%22machine%22:%2256%22},{%22test%22:%2217%22,%22branch%22:%221%22,%22machine%22:%2257%22}]) it looks fairly flat and stable until late in 2009-05-13. Zooming in on that range (http://graphs-new.mozilla.org/#tests=[{%22test%22:%2217%22,%22branch%22:%221%22,%22machine%22:%2255%22},{%22test%22:%2217%22,%22branch%22:%221%22,%22machine%22:%2258%22},{%22test%22:%2217%22,%22branch%22:%221%22,%22machine%22:%2256%22},{%22test%22:%2217%22,%22branch%22:%221%22,%22machine%22:%2257%22}]&sel=1242199337,1242470884) the first jump happens 11:44pm on 2009-05-13, which is before bug 492014 landed.
Those graphs also make the regression look like it's actually more about adding a huge amount of noise to the Talos results. Adding Alice and Catlee: can you guys look at the Txul regression being discussed here and help us to interpret the data?

Using the 2009-05-13 checkin range:

http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?startdate=2009-05-13&enddate=2009-05-14

I wonder if it might have been something in

http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?changeset=69b776e23172

that caused this, so moving to Core::Layout

another one that makes me nervous is:

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a183291b4467

which updated our NSS tag, cc'ing wtc.
Component: General → Layout
QA Contact: general → layout
Dump of some data from the time window in question is included below.

This seems to confirm the original range of 9b5c1b3ba645 to 367553b3abf1.  Note
that 46b703c76f3a and 560b588c0ae8 were pushed _after_ 367553b3abf1.  The 5.41%
increase looks like it's the same regression as the larger 9.86% one.

There's a slight dip on the 20th around 1pm followed by another rise around 5pm.
The ranges for these look like maybe:

95864d3d09b7 to 8278296006bc for the dip
http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=95864d3d09b7&tochange=8278296006bc

and

b5e00a65cc83 to 8494de32d9d6 for the second rise
http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=b5e00a65cc83&tochange=8494de32d9d6

These two later events are far less clear, so take this with a faily large
grain of salt.

Date                Revision     Txul value
2009-05-19 13:14:00 82d4f0cd8238 95.1579
2009-05-19 13:14:00 82d4f0cd8238 93.1111
2009-05-19 13:14:00 82d4f0cd8238 94.0
2009-05-19 14:49:00 cc1ad4713974 95.7895
2009-05-19 14:49:00 cc1ad4713974 95.6842
2009-05-19 14:49:00 cc1ad4713974 96.1053
2009-05-19 14:51:00 fe5a7beda408 93.6842
2009-05-19 14:51:00 fe5a7beda408 94.5789
2009-05-19 14:51:00 fe5a7beda408 94.6842
2009-05-19 16:43:00 9b5c1b3ba645 93.5789
2009-05-19 16:43:00 9b5c1b3ba645 95.9474
2009-05-19 16:43:00 9b5c1b3ba645 95.7778
2009-05-19 17:37:00 46b703c76f3a 102.857
2009-05-19 17:37:00 46b703c76f3a 109.526
2009-05-19 17:37:00 46b703c76f3a 106.053
2009-05-19 17:52:00 560b588c0ae8 105.684
2009-05-19 17:52:00 560b588c0ae8 106.526
2009-05-19 18:08:00 367553b3abf1 105.053
2009-05-19 18:08:00 367553b3abf1 109.579
2009-05-19 18:08:00 367553b3abf1 100.263
2009-05-19 19:41:00 9fef988ed375 101.947
2009-05-19 19:41:00 9fef988ed375 97.9375
2009-05-19 19:41:00 9fef988ed375 97.1579
2009-05-19 20:01:00 9821af3baba9 106.737
2009-05-19 20:01:00 9821af3baba9 105.263
2009-05-19 20:01:00 9821af3baba9 107.316
2009-05-19 21:45:00 f4adc0451c0d 104.684
2009-05-19 21:45:00 f4adc0451c0d 109.105
2009-05-19 21:45:00 f4adc0451c0d 98.6842
2009-05-19 22:05:00 9821af3baba9 102.579
2009-05-19 22:05:00 9821af3baba9 105.579
2009-05-19 22:05:00 9821af3baba9 102.947
2009-05-20 00:09:00 f4adc0451c0d 105.316
2009-05-20 00:09:00 f4adc0451c0d 107.842
2009-05-20 00:09:00 f4adc0451c0d 103.053
2009-05-20 01:34:00 c7babba8df56 104.471
2009-05-20 01:34:00 c7babba8df56 108.474
2009-05-20 01:34:00 c7babba8df56 105.278
2009-05-20 03:10:00 acd2d4638228 106.211
2009-05-20 03:10:00 acd2d4638228 108.211
2009-05-20 03:10:00 acd2d4638228 102.421
2009-05-20 04:18:00 acd2d4638228 107.263
2009-05-20 04:18:00 acd2d4638228 108.842
2009-05-20 04:18:00 acd2d4638228 107.0
2009-05-20 05:43:00 acd2d4638228 103.684
2009-05-20 05:43:00 acd2d4638228 103.789
2009-05-20 05:43:00 acd2d4638228 99.4737
2009-05-20 07:19:00 ae5dd47f6a03 99.4737
2009-05-20 07:19:00 ae5dd47f6a03 104.421
2009-05-20 07:19:00 ae5dd47f6a03 103.316
2009-05-20 07:37:00 acd2d4638228 100.556
2009-05-20 07:37:00 acd2d4638228 99.8947
2009-05-20 07:52:00 f57e2a9fb994 102.632
2009-05-20 07:52:00 f57e2a9fb994 107.368
2009-05-20 07:52:00 f57e2a9fb994 103.263
2009-05-20 08:02:00 edee09521af4 100.579
2009-05-20 08:02:00 edee09521af4 102.947
2009-05-20 08:52:00 6ed45f9587fd 101.105
2009-05-20 08:52:00 6ed45f9587fd 102.895
2009-05-20 08:52:00 6ed45f9587fd 102.474
2009-05-20 09:15:00 439e4b3e3f2d 105.421
2009-05-20 09:15:00 439e4b3e3f2d 102.263
2009-05-20 09:32:00 2704ea8db562 102.211
2009-05-20 09:32:00 2704ea8db562 101.706
2009-05-20 09:32:00 2704ea8db562 100.0
2009-05-20 10:43:00 d78ac0da4a3f 99.9474
2009-05-20 10:43:00 d78ac0da4a3f 103.056
2009-05-20 10:43:00 d78ac0da4a3f 102.421
2009-05-20 11:02:00 925e366b831b 100.579
2009-05-20 11:02:00 925e366b831b 101.368
2009-05-20 11:02:00 925e366b831b 101.105
2009-05-20 12:04:00 2af3e11314df 97.2105
2009-05-20 12:04:00 2af3e11314df 99.2632
2009-05-20 12:04:00 2af3e11314df 100.684
2009-05-20 12:55:00 95864d3d09b7 104.053
2009-05-20 12:55:00 95864d3d09b7 104.0
2009-05-20 12:58:00 8278296006bc 95.625
2009-05-20 12:58:00 8278296006bc 91.75
2009-05-20 12:58:00 8278296006bc 96.9474
2009-05-20 13:40:00 5ba8ffa2d6dd 102.053
2009-05-20 13:40:00 5ba8ffa2d6dd 101.444
2009-05-20 13:55:00 5134c1c002de 102.895
2009-05-20 14:07:00 90215ba771f8 99.4737
2009-05-20 14:07:00 90215ba771f8 99.2105
2009-05-20 14:09:00 39cd8ed1fe5a 100.105
2009-05-20 14:09:00 39cd8ed1fe5a 102.053
2009-05-20 14:09:00 39cd8ed1fe5a 100.105
2009-05-20 14:49:00 46bc144a2101 96.3889
2009-05-20 14:49:00 46bc144a2101 97.7222
2009-05-20 14:49:00 46bc144a2101 98.5263
2009-05-20 16:10:00 b5e00a65cc83 95.1176
2009-05-20 16:10:00 b5e00a65cc83 98.5789
2009-05-20 16:10:00 b5e00a65cc83 93.3684
2009-05-20 17:43:00 8494de32d9d6 109.684
2009-05-20 17:43:00 8494de32d9d6 107.263
2009-05-20 17:43:00 8494de32d9d6 100.632
2009-05-20 18:04:00 3329a3997d7b 108.211
2009-05-20 18:04:00 3329a3997d7b 105.579
2009-05-20 18:12:00 37cca97890fe 104.417
2009-05-20 18:12:00 37cca97890fe 106.895
2009-05-20 18:12:00 37cca97890fe 108.368
2009-05-20 18:54:00 564aec224cee 99.0
2009-05-20 18:54:00 564aec224cee 99.9444
2009-05-20 19:14:00 4079e1bbfbdc 100.632
2009-05-20 19:14:00 4079e1bbfbdc 108.263
2009-05-20 19:14:00 4079e1bbfbdc 101.947
2009-05-20 19:46:00 027583c55155 107.684
2009-05-20 19:46:00 027583c55155 105.0
2009-05-20 19:46:00 027583c55155 104.316
2009-05-20 20:38:00 287ba792e8ea 106.684
2009-05-20 20:38:00 287ba792e8ea 106.889
2009-05-20 20:38:00 287ba792e8ea 101.842
2009-05-20 21:16:00 72f42db5836b 108.526
2009-05-20 21:16:00 72f42db5836b 103.632
2009-05-20 21:17:00 ba76edffc635 106.632
2009-05-20 21:17:00 ba76edffc635 107.053
2009-05-20 21:17:00 ba76edffc635 109.474
2009-05-20 22:27:00 2895e3e4ac6e 105.421
2009-05-20 22:27:00 2895e3e4ac6e 105.579
2009-05-20 22:53:00 d4dcb532be6e 105.947
2009-05-20 22:53:00 d4dcb532be6e 106.158
2009-05-20 22:57:00 d7660183798a 106.421
2009-05-20 22:57:00 d7660183798a 106.684
2009-05-20 22:57:00 d7660183798a 105.474
8494de32d9d6	Marco Bonardo — Bug 493934 - Autocomplete queries are wrongly cutting away some result

This could at a maximum slowdown an autocomplete query, and that is not taken in count by TXul

d7071833d673	Marco Bonardo — Bug 493933 - When sorting bookmarks BY NONE we should take in count partitioning

This cannot slowdown bookmarks toolbar because we use a different query there, so that code path is not touched.

i'm not sure if i should also look at other patches in previous posted ranges, i took a look at bug 488966 -  Add a last_visit_date column with an index to moz_places but i don't see a connectio to a TXul regression only on XP.
David: your checkin here:

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0866be0a6600

from bug 490695 got us a TXul win on mozilla-central. Any way that it did the opposite thing on XP on 191?

Other possibility is

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/560b588c0ae8

which was bug 492014 which is tn again.

I'm going to block on this, and after we've frozen and have a stable tree we might want to play with backing some of these out and seeing what happens.
Flags: blocking1.9.1? → blocking1.9.1+
I put a break point on the line

nsIFrame* f = static_cast<nsIFrame*>(subdocView->GetClientData());

in nsSubDocumentFrame::BuildDisplayList in nsFrameFrame.cpp which is before any changes in bug 492014, and it never gets hit when running Txul locally (using these instructions to run Txul https://wiki.mozilla.org/Performance:Tinderbox_Tests#Txul:_XUL_window_open_time). So the code changed by bug 492014 isn't getting run during a Txul run.
dbaron: any possibility that this is you? Timothy has done a pretty robust job of proving that it wasn't him!
I would recommend experimentally backing out one or both of dbaron's checkins (0866be0a6600 and/or 4610c0a8f3cc) on 1.9.1 to see if it was one of those. Do I need approval for that?
(In reply to comment #11)
> I would recommend experimentally backing out one or both of dbaron's checkins
> (0866be0a6600 and/or 4610c0a8f3cc) on 1.9.1 to see if it was one of those. Do I
> need approval for that?

which two are you referring to?

and no, i don't think you need approval for a temporary backout to investigate this blocker.
(In reply to comment #5)
>
> another one that makes me nervous is:
> 
> http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a183291b4467
> 
> which updated our NSS tag, cc'ing wtc.

That changeset updated NSPR from NSPR_4_8_BETA1 to NSPR_4_8_BETA2.
The changes are very small.  They should not affect Txul on Windows
XP because
1. Most of the changes affect only one of these platforms: OpenVMS,
Mac OS X, and HP-UX.
2. The only cross-platform change is a no-op unless your
NSPR_LOG_MODULES environment variable's value contains "timestamp".
(In reply to comment #14)
> I backed out bug 490695 on the 1.9.1 branch to see if that fixes this.  (I
> propagated a typo of the bug number, though):

Jury's still out on Windows results, which is what we're really looking for here.  The one mac box that's reported so far shows no effect. Early indications are that this backout caused a 2% regression on linux Txul, though:

http://graphs.mozilla.org/#show=2424787,2421527,2418062,2418007,2417745
Any progress here?
It looks like my backout didn't help, so I relanded:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/6c2b9bec417f
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/560662a707ba


So, looking at the graph, it looks like there was a period on the afternoon of the 22nd when things returned to their pre-regression state, but then quickly reverted to regressed again:

http://graphs.mozilla.org/#show=2417579,2417613,2419200,2419307,2420846&sel=1242712861,1243149274

Does that give any useful hints?
There is also the graph data for mozilla-central where there was a similar increase a few days prior to the 1.9.1 increase. I tried to look at this in comment 4, but I might have mixed up the times. What time zone are the graphs in?
Pacific time (= "Mozilla Standard Time").
Unblocking, as I don't think we'd hold the release on this.

That said, I'd like us to keep looking at this while the tree isn't frozen to see if we can get it in time.

Johnny: any chance this is http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b380d9251b9b - Fixing bug 494051. Don't fall off trace when accessing the global property 'window'. r+sr=mrbkap@gmail.com, a=jonas@sicking.cc
Assignee: nobody → johnath
Flags: wanted1.9.1.x?
Flags: blocking1.9.1-
Flags: blocking1.9.1+
Uh, it really really shouldn't be, that should, if anything, make us faster. But I can back out to see if the graphs prove me wrong (and puzzle me immensely).
Backing out the fix for bug 494051 had no effect on Txul. But I won't be relanding that for 1.9.1 any more since the benefits we get from it as really close to none.
looks like last push in bug 484459 has brought a similar (8.98%) Txul decrease on 1.9.1, only on XP. could that be related?
I really doubt the sandbox change would have affected much of anything real; we only use sandboxes for PAC and session restore.  I have no idea why the machine shows a Txul change...
If any driver approves that, Boris suggested to backout his patch and see if the regressions comes back. Maybe this is somehow related to PGO.

I can eventually take care of backing out and check XP talos if Johnath has no time to look into it.
Johnathan: Are you still investigating this?
status1.9.1: --- → ?
Flags: wanted1.9.1.x?
(In reply to comment #28)
> Johnathan: Are you still investigating this?

No, I haven't been. The obvious culprits were backed out to no effect. Marco could still try his plan from comment 27, though I don't know if the intervening 2 months have added merge nightmare to any backout scenario.
Way old... resolving -> incomplete
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.