On Sep 20, 2011, at 3:39 PM, Ojan Vafai <ojan@chromium.org> wrote:
> On Tue, Sep 20, 2011 at 1:55 PM, Boris Zbarsky <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.
>
> 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?
Aren't these sped up in repeat calls on the JIT compiler? Seems mostly an issue about type boxing.