The detailed memgraph data collected from Membuster is saying there are many large Vectors, and they are a data segment of SharedBuffer of CachedResources, including CachedScript, CachedCSSStyleSheet, CachedImage etc. But important thing is that they also have decoded data too! This means we have double-sized data basically so long as CachedScript etc. is held by CachedScriptSourceProvider. For example, we have CachedScript, and it has decoded string. This means... We have duplicate data for this script, one in SharedBuffer and one in decoded String. The same thing can be said for CachedCSSStyleSheet, CachedImage etc. Instead of destroying SharedBuffer, we have a mechanism destroying decoded data (destroyDecodedData). But this would not be called so long as CachedScriptSourceProvider is holding this CachedScript. This basically means that we have duplicate data so long as we are in this page. If we navigate to the other page, we could purge decoded data (and we could purge CachedResource too.) For some CachedResource types, we should hold decoded data, and should purge SharedBuffer instead.
I’ll try this tomorrow. Plan is using Variant<SharedBuffer, String, ...> as data
Seems that blink folks are doing this. We should try. https://docs.google.com/document/d/1v0yTAZ6wkqX2U_M6BNIGUJpM1s0TIw1VsqpxoL7aciY/edit#heading=h.hydebxiwp5hv
We have a path using SharedBuffer as a content when it is ASCII. And seems that Membuster is using this path mainly, so maybe, this does not affect on memory usage of Membuster. But for image case, we should do it. And still, we should do it, but I'll check later since this would not affect on Membuster result.
For CachedImage case, // On Mac the NSData inside the SharedBuffer can be secretly appended to without the SharedBuffer's knowledge. // We use SharedBuffer's ability to wrap itself inside CFData to get around this, ensuring that ImageIO is // really looking at the SharedBuffer. We are already doing this, cool. Other possibility is, 1. non-ASCII string source code 2. script source code compression 3. style sheet source code compression
(In reply to Yusuke Suzuki from comment #4) > For CachedImage case, > > // On Mac the NSData inside the SharedBuffer can be secretly appended to > without the SharedBuffer's knowledge. > // We use SharedBuffer's ability to wrap itself inside CFData to get around > this, ensuring that ImageIO is > // really looking at the SharedBuffer. > > We are already doing this, cool. > > Other possibility is, > > 1. non-ASCII string source code > 2. script source code compression > 3. style sheet source code compression Wait, I need to check whether ImageIO is using this buffer directly or doing some fancy buffering internally.