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_nas...@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! > [image: image.png] > > -- > -- > Chromium Developers mailing list: chromium-...@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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/5e4943e4-bd91-462a-98f6-2d2796353d4cn%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XFBn4Fp1MBYSSHrkhAHPg8xu1-e-T2P0izawv3p90WAOA%40mail.gmail.com.
