Closed Bug 1100300 Opened 10 years ago Closed 9 years ago

6.44% Win8 TSPaint + Session Restore no Auto regresssion on Aurora (v.35) Nov 13 from push


(Core :: Graphics, defect)

Windows 8
Not set





(Reporter: jmaher, Unassigned)



(Keywords: perf, regression, Whiteboard: [talos_regression])

Graph server shows a regression:,52,31%5D%5D&sel=1408445681746,1416221681746&displayrange=90&datatype=running

I did some retriggers which you can see on tbpl:

After a series of retriggers, this is the change that takes us from ~620 -> 650:

I know we are disabling direct2D 1.1, but there is no performance win that I see which balances this out.  The graph above is a 90 day view.

I am surprised that we have such a large regression on a single test, maybe Yoric can help us figure out why this is so specific of a test?
oh, ts paint yields a 2.68% regression on win8 as well:,52,31%5D%5D&sel=none&displayrange=90&datatype=running

it doesn't show a corresponding win, so just like session restore no auto restore, both of these tests will be registering as an overall regression.

The good news is 2 tests canvasmark and tresize have a win, here is the net sum of the changes I see so far:
Summary: 6.44% Win8 Session Restore no Auto regresssion on Aurora (v.35) Nov 13 from push → 6.44% Win8 TSPaint + Session Restore no Auto regresssion on Aurora (v.35) Nov 13 from push
Best guess: direct2d is ~30ms slower to load than direct2d1.1, and this shows on startup.
Yoric, how is sessionrestore no auto restore different from sessionrestore?  Does the no auto version restore windows?
That's the main difference: "no auto restore" doesn't restore windows, it just loads the data but doesn't do anything meaningful with it.
so this is a regression in the no auto restore.  Quite possibly just the raw load (because ts paint and session restore no auto restore) by regressed is regressed here as it might have the highest startup costs, but when we actually restore tabs it does more work therefore masking or not being affected by this regression/change?
My hypothesis is that, indeed, when we do more work, these ~30ms are either masked or compensated somewhere else.
this has shipped and very old, closing this out.
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.