W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2012

Re: Optimize setting textContent?

From: Ojan Vafai <ojan@chromium.org>
Date: Tue, 14 Feb 2012 00:47:49 -0800
Message-ID: <CANMdWTthf75d2vhwi_-yVf7NeZmg_KkPewEdgY0Awws3+AFB3g@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: olli@pettay.fi, Anne van Kesteren <annevk@opera.com>, www-dom@w3.org, "Robert O'Callahan" <robert@ocallahan.org>, Stig Halvorsen <stighal@opera.com>
On Mon, Feb 13, 2012 at 8:39 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Feb 8, 2012 at 7:26 PM, Olli Pettay <Olli.Pettay@helsinki.fi>
> wrote:
> > On 02/08/2012 03:47 PM, Anne van Kesteren wrote:
> >>
> >> In https://bugzilla.mozilla.org/show_bug.cgi?id=725221 roc (cc'd, not
> >> subscribed to the list) suggests optimizing textContent by special
> >> casing the scenario where the first child is a text node and the string
> >> being set is non-empty. This would affect mutation observers and makes
> >> the setting algorithm more complicated, but it is also a performance win
> >> (in some implementations at least). Opinions?
> >
> > The main problem I have with this is that we would be making API
> > more inconsistent just because in some implementation(s) optimizing the
> > inconsistent API might be easier.
>
> I would imagine that replacing a node is slower in *all* browsers.
>
> I agree with Robert, the risk that this will break someone seems very
> small. The resulting behavior in fact seems nicer for developers in
> most situations. And the performance benefit seems real, though it
> would be interesting to see actual numbers for various browsers, which
> would also help verify my statement above.
>

I agree. For the record, I'd support changing this in WebKit and don't
expect it would be very controversial. I don't have strong opinions about
whether we should only do it in the single textnode child case or in the
first child is a textnode case. My intuition is for the latter because I
think the risk of web compatibility problems is so low that any extra
performance benefit it worth it.

Ojan
Received on Tuesday, 14 February 2012 08:48:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:09 GMT