Closed Bug 494255 Opened 16 years ago Closed 8 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: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.