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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Dec 16 09:56:47 PST 2009


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





--- Comment #16 from anton muhin <antonm at chromium.org>  2009-12-16 09:56:47 PST ---
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #7)
> > > This bug is quite devoid of any actual details of the speedup you got.  What
> > > was the win?  What did you test on?  Why is this the right tradeoff?
> > 
> > Sorry, Sam, didn't want to overload with details.
> > 
> > The speedup is ~10% (tested on Windows and Linux) for overall score for DOM
> > core of Dromaeo.
> 
> 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).

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



More information about the webkit-unassigned mailing list