On 7/12/13 3:34 PM, Kyle Huey wrote:
That means you have to eagerly create JS wrappers for every node in the DOM
tree.
True.
So you can't do lazy prototype setup
You still can as long as you don't have any nodes for a given prototype...
lazy wrapper creation
Indeed.
Those are big speed and size wins in Gecko ...
We should do some measurements here. Your typical JSObject is 4 words.
DOM JS objects in Gecko have 3 reserved slots. So that's 4 words + 24
bytes == 40 bytes on 32-bit and 56 bytes on 64-bit. Your typical web
page has several thousand nodes, so we're talking a few hundred KB. The
HTML5 spec has ~400k nodes, so there we're talking 20MB difference...
On the other hand, if we always have a JSObject for the node, then we
can maybe fuse the allocation and save one reserved slot (pointing to
the node) and one word in the node (pointing to the JS object). Maybe.
Then we're talking 28 bytes and 40 bytes overhead respectively. And
in practice web pages often touch their nodes from JS anyway, so this
would not be a cost for _every_ node, and for the ones that get touched
we can actually get savings from the fused allocation. I'm pretty sure
we'll still lose on things like the HTML5 spec, though.
The other big loser here will be things like XHR result documents.
The other source of bloat would be the prototype objects. We should
measure how often it happens that a page has nodes that would want a
given prototype but never has to actually instantiate that prototype object.
As far as performance goes, we should just measure it. E.g. in Gecko we
could try just forcing it to create JS wrappers for every node and
seeing how much of a hit there is on things like Tp and other benchmarks.
The other possible concern here is Olli's concern about GC having to
trace through known-live stuff while CC can actually stop traversing the
graph when it hits known-live things, which makes it easier to optimize
out the effect of large DOMs on the CC than on the GC... I'm not sure
what we can do about that.
-Boris
_______________________________________________
dev-servo mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-servo
