oh, this is a bigger regression than ween in bug 1014784. Here is a graph showing the details: http://graphs.mozilla.org/graph.html#tests=[[225,132,33]]&sel=1400578923000,1400751723000&displayrange=7&datatype=running I did some retriggers to ensure this is really the case: https://tbpl.mozilla.org/?tree=Fx-Team&fromchange=a3a74829a5cf&tochange=a6dcd4c2fb6b&jobname=Ubuntu%20HW%2012.04%20fx-team%20talos%20svgr here is more information about tsvg opacity: https://wiki.mozilla.org/Buildbot/Talos/Tests#tsvg-opacity
oh, to be clear this is caused by: http://hg.mozilla.org/integration/fx-team/rev/c3b86a5d52b6
I mistyped this, it is bug 937532
Summary: 66.8% svg opacity regression on linux32 from bug 973535 on May 21 (fx32) → 66.8% svg opacity regression on linux32 from bug 973532 on May 21 (fx32)
Tim, any reason for you to believe that bug 973532 could have caused this?
(In reply to Avi Halachmi (:avih) from comment #3) > Tim, any reason for you to believe that bug 973532 could have caused this? I have no clue why that should impact tsvg tests :/ I thought we didn't even hit this code path on talos runs other than TART.
Hmmm. Maybe that's related to bug 881590. I just remembered that we had similar tsvg problems when we cancelled a load in the hidden window. Maybe it's the inactive docShells that behaves funny again.
very likely. Anything we could push to try to validate that?
I tried starting to preload after the docShell has been set to inactive but that didn't work out. https://tbpl.mozilla.org/?tree=Try&rev=09c27b193c17 https://tbpl.mozilla.org/?tree=Try&rev=5c924346c60b http://perf.snarkfest.net/compare-talos/?oldRevs=09c27b193c17&newRev=5c924346c60b&submit=true No improvement unfortunately. I will try to push something that validates the assumption from comment #5.
for reference, this posted a 27.2% regression on the PGO builds of linux32.
Looking at this test for the past 90 days, I can say that: - Ubuntu 32 affected sharply - OS X 10.8 looks like affected (but not as sharp) - Ubuntu 64 looks like affected very mildly. - Windows OSs were not affected or affected only very(!) slightly. Very notable here is the difference between ubuntu 32 and 64. If I look at the past 90 days: - Ubuntu 32/64 were very noisy during March. 32 at the same level as this regression. http://graphs.mozilla.org/graph.html#tests=[[225,64,31],[225,64,24],[225,132,37],[225,132,25],[225,132,35],[225,132,33]]&sel=1393144411512,1400920411512&displayrange=90&datatype=running The only thing which regressed svg-opacity recently is cache v2 (bug 913806). It was turned on finally on 2014-05-16. Could this somehow be related?
Just for laughs, can we somehow retrigger/repush with cache v2 disabled? We need these prefs to disable the new cache: browser.cache.use_new_backend_temp = false browser.cache.use_new_backend = 0 (and to enable it, the first one should be true, for some reason it looks like browser.cache.use_new_backend isn't part of controlling the new cache. see bug 913806 comment 15 and 16).
I pushed multiple patches: http://perf.snarkfest.net/compare-talos/?oldRevs=dac70cc0f120&newRev=7b4b70965d6b&submit=true (cache v2 disabled, no perf gain) http://perf.snarkfest.net/compare-talos/?oldRevs=dac70cc0f120&newRev=b2e694135ffa&submit=true (docShell.isActive=false removed, no perf gain) http://perf.snarkfest.net/compare-talos/?oldRevs=dac70cc0f120&newRev=2e6e9ab381a4&submit=true (backout of c3b86a5d52b6 just to confirm, brings us back to old numbers indeed) So what else could it be in that changeset?
this is a pretty old bug, the trend of this test is improvements, so this issue (expecially 66%) is not seen overall: http://graphs.mozilla.org/graph.html#tests=%5B%5B225,132,33%5D,%5B225,53,33%5D%5D&sel=1380646402558,1412182402558&displayrange=365&datatype=running
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.