https://lab.hakim.se/domtree/ is slower with WR
Categories
(Core :: Graphics: WebRender, defect, P5)
Tracking
()
People
(Reporter: mayankleoboy1, Unassigned)
References
(Blocks 3 open bugs)
Details
Reporter | ||
Comment 1•6 years ago
|
||
Comment 3•6 years ago
|
||
Comment 4•6 years ago
|
||
Reporter | ||
Comment 5•6 years ago
|
||
2019-01-08T00:00:23: INFO : Narrowed inbound regression window from [f1ce520b, 23941690] (3 builds) to [f1ce520b, 996bf60e] (2 builds) (~1 steps left)
2019-01-08T00:00:23: DEBUG : Starting merge handling...
2019-01-08T00:00:23: DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=996bf60e0fce90cc42e7b59201d56ba0947b8cf2&full=1
2019-01-08T00:00:24: DEBUG : Found commit message:
Bug 1415987. Use ChooseScale to choose a scale in WebRender. r=jrmuizel
2019-01-08T00:00:24: DEBUG : Did not find a branch, checking all integration branches
2019-01-08T00:00:24: INFO : The bisection is done.
2019-01-08T00:00:24: INFO : Stopped
No idea why, but bug 1415987 massively improved this testcase with WR enabled.
Updated•6 years ago
|
Reporter | ||
Comment 6•6 years ago
|
||
@Jeff: I'm curious why bug 1415987 improved this bug, and bug 1448926 so much. Do you have an idea?
Comment 7•6 years ago
|
||
bug 1415987 made it so that we don't redraw the controls everytime that the scale changes.
Comment 8•4 years ago
|
||
On the render backend we spend a very large amount of time inserting into a BSP tree for plane splitting. The time is spent allocating many small vectors during each recursion of the inderstion function.
The scene is also re-built a lot so the scene builder thread is pretty much 100% busy, a lot fo the time being spent in vector allocations while adding primitives.
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 9•4 years ago
•
|
||
Latest profile : https://share.firefox.dev/3oODjOA
- 50% of WRRenderBackend is spent in etagere (the new allocator). Is this expected ?
- It feels similar to non WR now. Do you see any other low hanging fruits here, or does this page have any specific perf issue that you want to track ? If not, happy to close this bug
Comment 11•4 years ago
•
|
||
50% of WRRenderBackend is spent in etagere (the new allocator). Is this expected ?
It's not expected. Oddly, when profiling locally I see all of the time being spent in add_split_plane and the atlas allocator doesn't show up, which probably indicates that after a long session, the cache can get into a state where atlas allocations become more expensive, which is worth investigating.
I think that there's enough room for improvements here, including low hanging fruits with the plane splitting code, to keep this bug open.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 12•2 years ago
|
||
Does this look any better with the patches from bug 1768984?
Reporter | ||
Comment 13•2 years ago
|
||
This is the profile from latest nightly (which doesnt have patches from bug 1768984): https://share.firefox.dev/3tkdkDy
Comment hidden (obsolete) |
Reporter | ||
Comment 15•2 years ago
|
||
And here is the profile from https://hg.mozilla.org/mozilla-central/rev/963d3b67f5243687fcb5bc122a22a536caa9a9fd : https://share.firefox.dev/3UDk6Qq
Reporter | ||
Updated•2 years ago
|
Description
•