268kb per process for DisplayItemCache
Categories
(Core :: Graphics: WebRender, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox81 | --- | fixed |
People
(Reporter: mccr8, Assigned: mikokm)
References
(Blocks 1 open bug)
Details
(Keywords: perf-alert, Whiteboard: [overhead:200k])
Attachments
(1 file)
I'm seeing about 250kb of memory used by some DisplayItemCache data structures. I think this is DisplayItemCache::mSlots.
Here's an excerpt from one DMD report:
249,856 bytes (245,768 requested / 4,088 slop)
3.23% of the heap (3.23% cumulative)
4.38% of unreported (4.38% cumulative)
#02: mozilla::layers::DisplayItemCache::SetCapacity(unsigned long, unsigned long) (/Users/andrewmccreight/mc/gfx/layers/wr/DisplayItemCache.cpp:134)
#03: mozilla::widget::PuppetWidget::CreateRemoteLayerManager(std::__1::function<bool (mozilla::layers::LayerManager*)> const&) (/Users/andrewmccreight/mc/widget/PuppetWidget.cpp:565)
#04: mozilla::dom::BrowserChild::CreateRemoteLayerManager(mozilla::layers::PCompositorBridgeChild*) (/Users/andrewmccreight/mc/dom/ipc/BrowserChild.cpp:2648)
#05:
Here's another DMD entry:
24,576 bytes (20,488 requested / 4,088 slop)
0.32% of the heap (25.48% cumulative)
0.43% of unreported (34.56% cumulative)
#02: mozilla::layers::DisplayItemCache::SetCapacity(unsigned long, unsigned long) (/Users/andrewmccreight/mc/gfx/layers/wr/DisplayItemCache.cpp:136)
#03: mozilla::widget::PuppetWidget::CreateRemoteLayerManager(std::__1::function<bool (mozilla::layers::LayerManager*)> const&) (/Users/andrewmccreight/mc/widget/PuppetWidget.cpp:565)
#04: mozilla::dom::BrowserChild::CreateRemoteLayerManager(mozilla::layers::PCompositorBridgeChild*) (/Users/andrewmccreight/mc/dom/ipc/BrowserChild.cpp:2648)
#05: mozilla::dom::BrowserChild::InitRenderingState(mozilla::layers::TextureFactoryIdentifier const&, mozilla::layers::LayersId const&, mozilla::layers::CompositorOptions const&) (/Users/andrewmccreight/mc/dom/ipc/BrowserChild.cpp:2620)
As you can see, this about 3.5% of the total heap for an ad iframe, which is not great when we have Fission enabled. Does this cache really need to be this large in all content processes?
Bug 1624016 talks about adding memory reporting for DisplayItemCache, but maybe it missed some data structure? Or maybe that's for a Rust data structure which is different?
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #0)
As you can see, this about 3.5% of the total heap for an ad iframe, which is not great when we have Fission enabled. Does this cache really need to be this large in all content processes?
This cache is important because it allows us to reuse painting primitives and avoid excessive IPC in simple interactions like hovering over elements. The cache was supposed to grow dynamically from 1k to 10k elements based on the display list length, but it is not working properly due to a call to nsTArray::SetCapacity
, which allocates the full capacity regardless of the element count.
Bug 1624016 talks about adding memory reporting for DisplayItemCache, but maybe it missed some data structure? Or maybe that's for a Rust data structure which is different?
Yes, this was added for parent process Rust data structure.
Assignee | ||
Comment 2•5 years ago
|
||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Comment 4•5 years ago
|
||
bugherder |
Reporter | ||
Comment 6•5 years ago
|
||
From looking at the patch, it looks like this cache was reduced to around 10% of its original size, so the savings might be around 200kb per content process.
Comment 7•5 years ago
|
||
== Change summary for alert #26798 (as of Wed, 26 Aug 2020 04:07:43 GMT) ==
Improvements:
4% Base Content Heap Unclassified linux1804-64-shippable-qr opt 5,870,503.83 -> 5,648,507.33
4% Base Content Heap Unclassified linux1804-64-shippable-qr opt 5,869,876.67 -> 5,649,285.67
For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=26798
Description
•