Thanks Stefan for the explanation. Is there any way I can test or visualize that? I guess this should be reelected in the meminfra profile allocations but I am not sure at the moment about which meminfra category would reflect the memory allocated for rasterizations and its trees.
Thanks @Christian Biesinger <cbiesin...@chromium.org> for the heap profiler link. I'll check that out. --usama On Wed, Sep 8, 2021 at 2:35 PM Stefan Zager <sza...@chromium.org> wrote: > On Tue, Sep 7, 2021 at 2:21 PM Naseer, Usama <usama_nas...@brown.edu> > 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 < >> cbiesin...@chromium.org> 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 <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/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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB4rhN9zRkSe5eSh%3Dt_54pCZGJ4YxLXsvBcWKHPLiPCC73dAUQ%40mail.gmail.com.
