Interesting pattern regarding JS memory usage for DOM manipulations

36 views
Skip to first unread message

Usama Naseer

unread,
Sep 7, 2021, 4:53:10 PM9/7/21
to Chromium-dev
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!
image.png

Christian Biesinger

unread,
Sep 7, 2021, 5:09:30 PM9/7/21
to usama_...@brown.edu, blink-dev
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


--
--
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.
Reply all
Reply to author
Forward
0 new messages