Re: Node append

On 09/21/2011 01:39 AM, Ojan Vafai wrote:
> On Tue, Sep 20, 2011 at 1:55 PM, Boris Zbarsky <bzbarsky@mit.edu
> <mailto:bzbarsky@mit.edu>> wrote:
>
>     On 9/20/11 4:48 PM, Robin Berjon wrote:
>
>             I can probably live with overloading things like appendChild
>             to take arrays as long as we keep in mind that this will
>             slow down every single appendChild call in the common case
>             of a node being passed.  Presumably we're ok with this,
>             since we're discussing it.
>
>
>         I would assume that it depends on how much of a hit we're
>         talking about.
>
>
>     It really depends on what other work is involved in the appendChild
>     call, obviously.
>
>     In the case of Gecko today, I would expect about a 30-40% hit or so,
>     without having actually measured carefully.  We're working on
>     reducing that, but also working on speeding up the common case, of
>     course.  Where the final hit of an overloaded method compared to a
>     non-overloaded one will converge is still an open question and
>     likely to depend on particular hardware architectures,
>     implementation strategies, etc... (e.g. if you make both slow enough
>     you could obviously have no appreciable hit for the overloaded case).
>
>
> I'd like to see all these methods take any of the following: node,
> string, array, nodelist.

Why? Why couldn't there be separate method(s) which take string/array 
etc and keep the old appendChild etc as they are now (in DOM 3, not in 
latest DOM 4 draft)


>
> The added benefit of these APIs is worth some performance hit. Also, as
> people start using these APIs effectively, many things will be more
> efficient, e.g. appending an array should be faster than appending each
> node inside the array with individual appendChild calls, right?
>
> Ojan

Received on Sunday, 2 October 2011 10:39:28 UTC