On Tue, Sep 7, 2021 at 2:21 PM Naseer, Usama <[email protected]> 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 < > [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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB4rhN_MWxzFHia9SGWgOjxjTkzWbopRJOVf-TOifEXa8pfiPg%40mail.gmail.com?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/CAHOQ7J8_-Yo5db%2BkJZwwX21CfP%2BBmxYeudUrbarCcT_WehvjGg%40mail.gmail.com.
