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

Thu Dec 24 07:47:14 PST 2009

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

--- Comment #20 from anton muhin <antonm at chromium.org>  2009-12-24 07:47:14 PST ---
Sam, all,

first of all, sorry for long delay and merry Christmas.

(In reply to comment #19)
> 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.

That's a good idea.

What I did.  I logged (every 100th time) number of nodes (liveNodeSet.size())
and number of wrapped nodes (actually getDOMNodeMap().size()) on 4 events: Node
creation/destruction, node wrapper addition and removal (if anyone is
interested, I'd post a patch).

Then I processed this file offline for various sites.  To estimate current
overhead I used three measures: original_min = 2 * 8 * wrapped nodes (2 due to
two times bigger underlying arrays size), original_max = 6 * 8 * wrapped nodes
(accounting for shrink strategy) and just original = 4 * 8 * wrapped nodes
(kind of average).  Please note that this doesn't account for deleted entries
(which live as tombstones until rehashed/shrinked/expanded), so those numbers
are underestimates.

To account for overhead by this patch + new Node map implementation I used the
following formula:

4 * nodes + 4 * wrapped + 2 * 1024 (2K due to the current chunk size which is
half of page).

Results:

=== membuster

avg nodes: 59339.0, avg wrapped: 9968.6 (16.799%)

measure: original_min
max overhead: 197892 bytes (193.3K) for 76867 9302
max win: -440 bytes (-0.4K) for 3086 1236
average: -117.0K

measure: original_max
max overhead: 13936 bytes (13.6K) for 3005 3
max win: -439620 bytes (-429.3K) for 69224 16331
average: 194.5K

measure: original
max overhead: 49756 bytes (48.6K) for 76712 9255
max win: -178324 bytes (-174.1K) for 69224 16331
average: 38.8K

=== Dromaeo, DOM core

avg nodes: 167563.1, avg wrapped: 62046.0 (37.028%)

measure: original_min
max overhead: 1267224 bytes (1237.5K) for 679459 121055
max win: -2096996 bytes (-2047.8K) for 290936 271899
average: 70.6K

measure: original_max
max overhead: 84992 bytes (83.0K) for 28557 711
max win: -10797764 bytes (-10544.7K) for 290936 271899
average: 2009.5K

measure: original
max overhead: 96368 bytes (94.1K) for 28557 711
max win: -6447380 bytes (-6296.3K) for 290936 271899
average: 1040.0K

=== Dromaeo, JS libs

avg nodes: 210501.8, avg wrapped: 74075.6 (35.190%)

measure: original_min
max overhead: 276512 bytes (270.0K) for 70872 752
max win: -738036 bytes (-720.7K) for 528847 237956
average: 43.8K

measure: original_max
max overhead: 252448 bytes (246.5K) for 70872 752
max win: -8352628 bytes (-8156.9K) for 528847 237956
average: 2358.7K

measure: original
max overhead: 264480 bytes (258.3K) for 70872 752
max win: -4545332 bytes (-4438.8K) for 528847 237956
average: 1201.2K

=== Apple.com and then click store

avg nodes: 1151.9, avg wrapped: 239.3 (20.776%)

measure: original_min
max overhead: 7812 bytes (7.6K) for 2233 264
max win: 0 bytes (0.0K) for -1 -1
average: -3.7K

measure: original_max
max overhead: 380 bytes (0.4K) for 408 75
max win: -12748 bytes (-12.4K) for 2351 550
average: 3.8K

measure: original
max overhead: 3588 bytes (3.5K) for 2233 264
max win: -3948 bytes (-3.9K) for 2351 550
average: 0.0K

=== Google.ru + search for Chromium

avg nodes: 399.9, avg wrapped: 146.2 (36.549%)

measure: original_min
max overhead: 4152 bytes (4.1K) for 802 92
max win: 0 bytes (0.0K) for -1 -1
average: -1.8K

measure: original_max
max overhead: 1648 bytes (1.6K) for 175 25
max win: -9664 bytes (-9.4K) for 449 307
average: 2.7K

measure: original
max overhead: 2680 bytes (2.6K) for 802 92
max win: -4752 bytes (-4.6K) for 449 307
average: 0.4K

=== http://www.w3.org/ + Reload

avg nodes: 780.0, avg wrapped: 101.7 (13.040%)

measure: original_min
max overhead: 6392 bytes (6.2K) for 1086 0
max win: 0 bytes (0.0K) for -1 -1
average: -3.9K

measure: original_max
max overhead: 6392 bytes (6.2K) for 1086 0
max win: -15640 bytes (-15.3K) for 1199 511
average: -0.7K

measure: original
max overhead: 6392 bytes (6.2K) for 1086 0
max win: -7464 bytes (-7.3K) for 1199 511
average: -2.3K

I'd say those numbers show that actually Chromium could even reduce its memory
usage.

> > > 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.

Thanks a lot for clarifications.  That sounds like an interesting idea, however
I'd postpone it as it adds some notable complications into the code (need to
treat nodes and elements separately).   YMMW, of course.

And just in case, I'd be off from Jan, 1 to Jan, 11.

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