On 6/30/14, 3:00 PM, Jussi Kalliokoski wrote:
There are various approaches to that, all cost something, but the
current approach is not free either.
Sure.
One heavy-handed optimization for
the poor performance common case is to have Object's struct contain a
pointer to a Node's host object
There are non-Node objects browsers have to support too, fwiw.
Would it help the discussion if UA implementors described how they solve
these problems now?
Memory footprint is 32bits on ARM and x86, and 64
bits on 64bit environments, per every Object, so pretty damn high.
Yep, which is why implementations don't do this. It's actually higher
than that because of alignment requirements...
Aside, out of curiosity, which is more problematic in DOM currently:
creation or appending of nodes?
Problematic in what sense? You mean time cost?
It's hard to say and depends a lot on context: creation involves a lot
more memory traffic; appending to a node depends a lot on whether that
node is in the document, etc.
These different in-memory layouts can be applied to the state behind the
pointer.
No, I mean different in-memory layouts for the JS object itself, not for
the DOM object it points to. For example, for some objects we (Gecko in
this case) want to have extra built-in slots for caching particular data
for the JIT to access quickly.
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
