Closed Bug 1066817 Opened 6 years ago Closed 6 years ago
5-7% Windows and linux Session Restore regression on Aurora (v
.34) when we uplifted
Session Restore has had some interesting regressions over the last 2 months. Win8 6.09%: http://graphs.mozilla.org/graph.html#tests=[[313,52,31],[313,63,31]]&sel=none&displayrange=90&datatype=running Here are some values for Mozilla Inbound PGO builds: July 24 (33 uplifted to Aurora): ~1420 August 11: ~1430 August 14: ~1440 August 20: ~1350 (bug 1053517) August 21: ~1375 (bug 1062899 tracks this) August 24: ~1390 Now for Win7: http://graphs.mozilla.org/graph.html#tests=[[313,52,25],[313,63,25]]&sel=none&displayrange=90&datatype=running This is very similar to Win8, here are the values of concern: July 24 (33 uplifted to Aurora): ~1400 August 11: ~1410 August 14: ~1425 August 20: ~1400 (bug 1053517) August 21: ~1420 (bug 1062899 tracks this) August 24: ~1440 And winXP: http://graphs.mozilla.org/graph.html#tests=[[313,52,37],[313,63,37]]&sel=1402777246082,1410553246082&displayrange=90&datatype=running July 24 (33 uplifted to Aurora): 1165 August 11: ~1180 August 14: ~1190 August 20: ~1200 <notice, no drop here like win7/win8> August 21: ~1225 (bug 1062899 tracks this) <notice, no august 24 regression>
And session restore no auto on winxp has this problem: July 24 - ~478 Aug 11 - ~485 Aug 14 - ~490 Aug 21 - ~502
linux32 session restore test: July 24: ~1190 July 25: ~1270 (backout of bug 354493 - both inbound and aurora) Aug 14: ~1280 Aug 17: ~1270 (small fix) Aug 19: ~1300 Aug 20: ~1250 (talos update, and bug 559505 localstore.rdf fix - applied to inbound and aurora) you can see a similar pattern here, the 11th/14th has a common regression pattern on various platforms.
Summary: 5-7% Windows Session Restore regression on Aurora (v.34) when we uplifted → 5-7% Windows and linux Session Restore regression on Aurora (v.34) when we uplifted
Joel, do you think this is severe enough that it should go into "known issues" for 34 release?
We are looking at a solid set of ~5% regressions on this test: http://graphs.mozilla.org/graph.html#tests=%5B%5B313,53,33%5D,%5B313,53,35%5D,%5B313,53,25%5D,%5B313,53,37%5D%5D&sel=1406393944263,1414169944263&displayrange=90&datatype=running Is this worthwhile of a line item in the release notes, probably not. Session Restore is not an operation that most people experience every day. In our test we have a large volume of sessions to restore, but we want to make sure that we don't do anything crazy. In the case of this bug, we had 3-4 small regressions sneak in and when we uplift it looks larger than life. For reference we are talking about 5% of 1.x seconds for an operation that is not very frequent (as compared to rendering data). I wish I knew more of why this is the case so we could document what features have affected session restore.
Thank you! It sounded so drastic. 5% of 1 second sounds less so from my point of view!
(In reply to Liz Henry :lizzard from comment #5) > Thank you! It sounded so drastic. 5% of 1 second sounds less so from my > point of view! I agree. I'm going to drop tracking but nom this for the Firefox backlog.
Slow creep and overall minimal impact, this doesn't seem actionable.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: firefox-backlog? → firefox-backlog-
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.