[Webkit-unassigned] [Bug 32430] [v8, dom] Add a pointer field to C++ Node class

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=32430





--- Comment #19 from Sam Weinig <sam at webkit.org>  2009-12-18 17:41:34 PST ---
> > At what cost?  What was the change in memory use?
> 
> First answer: I don't know, but hopefully we have enough infrastructure to see
> the impact on Chromium (and I hope Safari won't be affected at all).
> 
> Some more details.  I carried on completely unscientific experiment: opened big
> GMail account in Chromium and got three snapshots.  Numbers are (first number
> is total number of Nodes as reported by liveNodeSet (see Node.cpp) vs. number
> of wrapped Nodes:
> 
> 1) 22945/3103
> 2) 35055/6911
> 3) 37223/7012.
> 
> Now embedding a pointer into Node we pay 4 bytes per each Node.  However, this
> pointer allows to use less memory for HashTables (in CL to be send for review).
>  My estimates:
> 
> 1) Currently we use 8 bytes per entry in the HashMap (4 bytes for Node pointer
> and 4 bytes for a handle), however HashMap allocated blocks which are from
> twice to six times bigger than necessary, let's average that as 4 times, so we
> allocate 32 bytes per each wrapped node.
> 
> 2) If all CLs in, we would have only 4 bytes overhead per wrapped node (plus
> some constant overhead for the rest of unused chunk).
> 
> So roughly we actual memory usage would be less, if we wrap every ~7th node. 
> Numbers for my GMail run shows something like one wrapped per 5-7 nodes.
> 
> Definitely that's not a prove, but kind of evidence that idea at least has a
> chance.
> 
> Taking it from other side 37223 * 4 gives me 145.5K of overhead, once again,
> looks reasonable for me (but I am biased).

These are interesting numbers, but I think a more scientific approach would
better.  I would recommend running the membuster test
(http://random.pavlov.net/membuster/index.html) and using the membuster memory
harness to test the memory usage during Dromeo before and after your change.  I
don't plan on trying to block your change, but these numbers would be very
valuable for trying to decide if this is the right tradeoff to make.

> > Another question: Is putting this pointer on Node really the right choice? We
> > have discussed specializing Element or  even HTMLElement to avoid the cost for
> > every Node (Text nodes for instance). Did you measure which type of Nodes this
> > would be the biggest win for?
> 
> Sorry, could you elaborate?  Was it discussed in public?  If yes, could you
> give me a pointer to the thread?

I don't have a pointer, but this was discussed at some amount of length with
Dimitri Glazkov when the v8 stuff first landed, and at that time, we decided
that we would not use an intrusive pointer without additional memory testing. 
The specializing for Element idea was to just put an intrusive pointer only on
Elements (instead of all Nodes), based on the theory that Elements are the most
likely to have a wrapper and that all Nodes should not have to pay the price.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.