@@initialize, or describing subclassing with mixins
Jussi Kalliokoski
jussi.kalliokoski at gmail.com
Mon Jun 30 12:38:24 PDT 2014
On Mon, Jun 30, 2014 at 10:16 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> 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.
>
Indeed, but as I mentioned, it's but one approach out of many.
> Would it help the discussion if UA implementors described how they solve
> these problems now?
Yess, please! +9999
> 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...
Affirmative.
>
> Aside, out of curiosity, which is more problematic in DOM currently:
>> creation or appending of nodes?
>>
>
> Problematic in what sense? You mean time cost?
>
Yup, that was the original intent, but actually both memory and time
complexity are of interest. But I'm infinitely curious so this is probably
not the right place. I'm not demanding anything, but a blog post about DOM
internals performance would be a real treat for people like me. ;)
> 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.
Right.
> 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.
>
As I suggested in one approach, for "natural" instances (in lack of a
better word) of Nodes can have all the in-memory layout optimizations they
need. The difference between self-hosting with for example symbols (either
in userland or spec language) to inlining the state internally is not
observable to the spec language or the userland (other than in performance).
-Boris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140630/14e65ef2/attachment-0001.html>
More information about the es-discuss
mailing list