Re: [chromium-dev] Interesting pattern regarding JS memory usage for DOM manipulations

[Christian Biesinger]

chromium-dev->bcc, +blink-dev

Hi Usama,

if you add a node at the top of tree, reparenting the existing DOM nodes, we recreate the layout tree and thus need to redo all layout. If you add a leaf node, we keep most of the layout state and don't recreate the layout objects, so it is much faster.

Christian

On Tue, Sep 7, 2021 at 4:52 PM Usama Naseer <usama_...@brown.edu> wrote:

Hi,

I am working on profiling Chrome's memory usage for popular websites and I have come across an interesting observation that I am currently unable to decipher.

Adding a DOM node (e.g., text or image) has a memory implication as the browser allocates some memory to store the content and render it on screen. One peculiar aspect I have observed is that this memory highly depends on "where" the new node is inserted. I created a bunch of synthetic web pages and measured the memory usage of browser when (i) a node is inserted to the top of the tree (i.e., added to the top and the existing nodes become its children), and (ii) at the bottom of the tree (i.e., leaf). In the figure below, I insert one such node every 10ms to two kind of trees. The "single-child" case is of interest here and it corresponds to a chain on nodes, e.g., div_1->div_2->div_n. If I insert a new node (div_x) to the top of the chain (i.e, div_x->div_1->div_2->div_n) versus at the bottom (i.e., div_1->div_2->div_n->div_x), the memory usage pattern is quite different. Note that the DOM size/content is exactly the same across the different tests.

Basically, for the top insert, the whole chain requires a relayout (Layout call in Chrome touches every node in the DOM), while for the bottom insert case the blast radius of the layout is much narrower. I observe "Layout" and " CompositorFrameSink" to be two calls emitted in the Chrome timeline. What I am unable to understand is "why is the memory usage pattern so different?". It would make total sense if we were talking about computation (higher the number of nodes that need layout, the more CPU cycles it requires), but I am unable to understand the discrepancy in the memory. Perhaps it has something to do with the CompositorFrameSink call.

If anyone has any suggestions or idea about this, I would highly appreciate it!

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/5e4943e4-bd91-462a-98f6-2d2796353d4cn%40chromium.org.

[Naseer, Usama]

Hi Christian,

Thanks for the response. I understand that adding on top requires a re-layout and should consume more CPU cycles. But it was the discrepancy in memory usage that stood out to me. Does each re-layout allocate new memory to store the new layout objects? It seems like this memory is not getting garbage collected instantly. For context, I got the following response from memory-dev group about moving LayoutObject to oilpan.

"There is a project to move LayoutObjects to oilpan (gc) (https://crbug.com/1030176) so heavier layouts could be allocating more temporary memory which will later get gc'd."

--usama

[Stefan Zager]

On Tue, Sep 7, 2021 at 2:21 PM Naseer, Usama <usama_...@brown.edu> wrote:

Hi Christian,

Thanks for the response. I understand that adding on top requires a re-layout and should consume more CPU cycles. But it was the discrepancy in memory usage that stood out to me. Does each re-layout allocate new memory to store the new layout objects? It seems like this memory is not getting garbage collected instantly. For context, I got the following response from memory-dev group about moving LayoutObject to oilpan.

"There is a project to move LayoutObjects to oilpan (gc) (https://crbug.com/1030176) so heavier layouts could be allocating more temporary memory which will later get gc'd."

LayoutObject garbage collection has not been enabled by default, so it wouldn't explain the memory discrepancy. It would, however, be interesting to run your test with the feature enabled (not sure what flag to use on the command line, someone on memory-dev could probably answer that).

My best guess is that the extra memory is due to more rasterization tile work. The compositing code maintains two sets of rasterized output: the "active tree", which is the pixels currently being displayed; and the "pending tree", which is the next set of pixels to be displayed. When the differences between the active and pending trees are small, we use cache-ing to minimize the duplication of rasterized output. When you manipulate the DOM tree at the top, it invalidates the pixels for the entire subtree, so everything is a cache miss.

Hope that helps.

 

--usama

On Tue, Sep 7, 2021 at 5:08 PM Christian Biesinger <cbies...@chromium.org> wrote:

chromium-dev->bcc, +blink-dev

Hi Usama,

if you add a node at the top of tree, reparenting the existing DOM nodes, we recreate the layout tree and thus need to redo all layout. If you add a leaf node, we keep most of the layout state and don't recreate the layout objects, so it is much faster.

Christian

On Tue, Sep 7, 2021 at 4:52 PM Usama Naseer <usama_...@brown.edu> wrote:

Hi,

I am working on profiling Chrome's memory usage for popular websites and I have come across an interesting observation that I am currently unable to decipher.

Adding a DOM node (e.g., text or image) has a memory implication as the browser allocates some memory to store the content and render it on screen. One peculiar aspect I have observed is that this memory highly depends on "where" the new node is inserted. I created a bunch of synthetic web pages and measured the memory usage of browser when (i) a node is inserted to the top of the tree (i.e., added to the top and the existing nodes become its children), and (ii) at the bottom of the tree (i.e., leaf). In the figure below, I insert one such node every 10ms to two kind of trees. The "single-child" case is of interest here and it corresponds to a chain on nodes, e.g., div_1->div_2->div_n. If I insert a new node (div_x) to the top of the chain (i.e, div_x->div_1->div_2->div_n) versus at the bottom (i.e., div_1->div_2->div_n->div_x), the memory usage pattern is quite different. Note that the DOM size/content is exactly the same across the different tests.

Basically, for the top insert, the whole chain requires a relayout (Layout call in Chrome touches every node in the DOM), while for the bottom insert case the blast radius of the layout is much narrower. I observe "Layout" and " CompositorFrameSink" to be two calls emitted in the Chrome timeline. What I am unable to understand is "why is the memory usage pattern so different?". It would make total sense if we were talking about computation (higher the number of nodes that need layout, the more CPU cycles it requires), but I am unable to understand the discrepancy in the memory. Perhaps it has something to do with the CompositorFrameSink call.

If anyone has any suggestions or idea about this, I would highly appreciate it!

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/5e4943e4-bd91-462a-98f6-2d2796353d4cn%40chromium.org.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB4rhN_MWxzFHia9SGWgOjxjTkzWbopRJOVf-TOifEXa8pfiPg%40mail.gmail.com.

[Christian Biesinger]

On Wed, Sep 8, 2021 at 2:35 PM Stefan Zager <sza...@chromium.org> wrote:

On Tue, Sep 7, 2021 at 2:21 PM Naseer, Usama <usama_...@brown.edu> wrote:

Hi Christian,

Thanks for the response. I understand that adding on top requires a re-layout and should consume more CPU cycles. But it was the discrepancy in memory usage that stood out to me. Does each re-layout allocate new memory to store the new layout objects? It seems like this memory is not getting garbage collected instantly. For context, I got the following response from memory-dev group about moving LayoutObject to oilpan.

"There is a project to move LayoutObjects to oilpan (gc) (https://crbug.com/1030176) so heavier layouts could be allocating more temporary memory which will later get gc'd."

LayoutObject garbage collection has not been enabled by default, so it wouldn't explain the memory discrepancy. It would, however, be interesting to run your test with the feature enabled (not sure what flag to use on the command line, someone on memory-dev could probably answer that).

My best guess is that the extra memory is due to more rasterization tile work. The compositing code maintains two sets of rasterized output: the "active tree", which is the pixels currently being displayed; and the "pending tree", which is the next set of pixels to be displayed. When the differences between the active and pending trees are small, we use cache-ing to minimize the duplication of rasterized output. When you manipulate the DOM tree at the top, it invalidates the pixels for the entire subtree, so everything is a cache miss.

Hope that helps.

It may be interesting to look at a heap profile:

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/memory-infra/

Christian

[Stefan Zager]

On Wed, Sep 8, 2021 at 6:16 PM Naseer, Usama <usama_...@brown.edu> wrote:

Thanks Stefan for the explanation. Is there any way I can test or visualize that? I guess this should be reelected in the meminfra profile allocations but I am not sure at the moment about which meminfra category would reflect the memory allocated for rasterizations and its trees.

Some reading for you...

https://source.chromium.org/chromium/chromium/src/+/main:docs/memory-infra/probe-cc.md

[Naseer, Usama]

Thanks Stefan for the explanation. Is there any way I can test or visualize that? I guess this should be reelected in the meminfra profile allocations but I am not sure at the moment about which meminfra category would reflect the memory allocated for rasterizations and its trees.

Thanks @Christian Biesinger for the heap profiler link. I'll check that out.

--usama

On Wed, Sep 8, 2021 at 2:35 PM Stefan Zager <sza...@chromium.org> wrote: