Closed Bug 837885 (australis-tabs-perf) Opened 12 years ago Closed 4 years ago

Australis tabs performance tracking

Categories

(Firefox :: Theme, defect)

defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: MattN, Unassigned)

References

(Depends on 1 open bug, )

Details

(Keywords: meta)

Attachments

(1 file)

See existing discussions in bug 738491 comment 76 and bug 738491 comment 79. Tab open and close profiling instructions are at bug 824845 comment 7. This bug will be for investigations. Patches to improve performance should be handled in dependencies.
Alias: australis-tabs-perf
Depends on: 837898
See also: Bug 837535 - tabs and newtab-button paint more than one gradient. Since currently gradients are expensive, we might be able to reduce the number of gradients which should be rendered on each animation frame. Bug 837542 - tab animation uses a lot of pattern-cache memory. This is caused by many cache misses when animating tabs (due to changing tab size which creates a new cache key, and probably unrelated to calc(..) in tab-size). Cache misses are also expensive in performance since we have to re-generate the gradient pattern if we can't reuse an existing one. MattN suggested to use 1px tiles for the background gradients as a solution for the cache misses. Need to verify that it speeds up paints. Bug 835284 tries to cache gradient tiles. Patch V1 Part 2 is a bit hacky, but it caches linear gradients as 1px tiles. This seems to eliminate the cache misses during tab animation, and results in almost half of the original paint time per animation frame. Not sure yet how much of this win relates to the cached tiles, and how much of it to the elimination of cache misses.
(In reply to Avi Halachmi (:avih) from comment #1) > Bug 837542 - tab animation uses a lot of pattern-cache memory. >... > MattN suggested to use 1px tiles for the background gradients as a solution for > the cache misses. Need to verify that it speeds up paints. I just tried it on the UX branch (patch: http://mattn.pastebin.mozilla.org/2114648 ). I can confirm it eliminates the cache misses during tab animation, and also eliminates the resulting memory spike. However, paint performance seem to stay the same. > Bug 835284 tries to cache gradient tiles. ... > Not sure yet how much of this win relates to the cached tiles, and how much > of it to the elimination of cache misses. Right now, it seems that the cached 1px tiles bring the speedup.
Depends on: 839660
Suggested tab animation performance test: Setup: - Have the tab-animation-repeat patch applied - Have a clean profile - Hidden navigation bar - Have 3 tabs open and the browser wide enough to have space left at the tabstrip for another tab - Create (bool) and set browser.tabs.animationLogging.enabled = true - Create (int) and set browser.tabs.animationLogging.repeatCount = 15 "sequence": - Open a new tab using the KB - Move the mouse away from the browser - Close the last tab - Wait for 15 times tab close/open - Write down the avereges of 15 animations for open/close To get the following results: - Start the browser, wait 10s (there's some layer manager swap 5s after browser startup) - Few (~5) "warm up" runs of "sequence" without closing the browser, with few seconds between runs. - Few more (~5) runs (still without closing the browser), write down average paint time to which it converges (for both tab open and tab close) This above procedure was executed on m-c and the ux branches from today, with and without the cache-key patch (from bug 838758). Average paint times results (in ms) (on windows 7 x64, non-transparent Aero theme, i7-3630qm, HD4000) ------------------------------------- m-c open: 3.5 close: 3.3 m-c cache-key open: 2.6 close: 2.4 ux open: 7.3 close: 5.2 ux cache-key open: 6.9 close: 5.3
Bug 838758 comment #15 adds measurements with the same builds on AMD E450 and Intel Atom N450 (D2D is disabled by default on those platforms, which generally makes tab animation faster).
There's another possible reason for bad tab animation performance (regardless of australis, but will probably affect the average frame intervals which we measure here): timing skew caused by the timer filter. See bug 590422 comment #21 and 22.
Whiteboard: [Australis:M?]
Depends on: 880554
Depends on: australis-ts
Depends on: 880620
Depends on: australis-tpaint
Depends on: 889768
Depends on: 890033
Depends on: australis-tart
Whiteboard: [Australis:M?] → [Australis:M?][Australis:P1]
Depends on: 904889
Depends on: 913227
Depends on: 914617
Depends on: 915352
Depends on: 915521
Depends on: 916859
Depends on: 916946
Depends on: 917795
Depends on: 919541
Depends on: 919947
Depends on: 920589
Depends on: 921038
Depends on: 921051
Depends on: 922207
Depends on: 924181
Depends on: 924182
Depends on: 924201
Depends on: 924415
Depends on: 925413
Depends on: 925415
No longer depends on: 925415
Depends on: 925514
Depends on: 921673
The investigations have been completed, and the last TART blocker has been lifted. We're not blocking on this tab stuff anymore.
Whiteboard: [Australis:M?][Australis:P1]
Depends on: 936469
Outdated?
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: