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 On Tue, Sep 7, 2021 at 5:08 PM Christian Biesinger <[email protected]> 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 <[email protected]> > 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: [email protected] >> 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 [email protected]. >> 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 [email protected]. 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.
