Interesting pattern regarding JS memory usage and DOM manipulations

[Usama Naseer]

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!

[Egor Pasko]

Hi Usama,

that's an interesting observation. Have you seen significant differences in heap snapshots after 25s?

--
You received this message because you are subscribed to the Google Groups "memory-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to memory-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/memory-dev/f8a546dc-9611-4a2c-92a1-19322728788bn%40chromium.org.

[Usama Naseer]

Hi Egor,

I do not see any significant change in JS Heap Size (if that's what you meant by the heap snapshot). To clarify, I generating the memory timeline through the meminfra tool and plotting the sum of "process_total" memory for the 3 processes (browser, gpu and renderer).

[Philip Rogers]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/memory-dev/82078da8-0e14-47fc-b77b-cb259d2103fan%40chromium.org.

[Usama Naseer]

This is interesting. Let me try to check the meminfra allocations to make sure that this indeed is the culprit.