Re: [XHR2] ArrayBuffer integration from James Robinson on 2010-09-28 (public-webapps@w3.org from July to September 2010)

From: James Robinson <jamesr@google.com>
Date: Tue, 28 Sep 2010 12:05:11 -0700
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Chris Marrin <cmarrin@apple.com>, Michael Nordman <michaeln@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Jian Li <jianli@chromium.org>, Anne van Kesteren <annevk@opera.com>, Julian Reschke <julian.reschke@gmx.de>, Kenneth Russell <kbr@google.com>, Vladimir Vukicevic <vladimir@mozilla.com>, Chris Rogers <crogers@google.com>
Message-ID: <AANLkTimk=2FB-H+tzMt+XVGO4g5xR-64SRqVV7JT49xq@mail.gmail.com>

On Tue, Sep 28, 2010 at 9:39 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 9/28/10 10:32 AM, Chris Marrin wrote:
>
>> I'd hate the idea of another flag in XHR. Why not just keep the raw bits
>> and then convert when responseText is called? The only disadvantage of this
>> is when the author makes multiple calls to responseText and I would not
>> think that is a very common use case.
>>
>
> It's actually reasonably common; Gecko had some performance bugs filed on
> us until we started caching the responseText (before that we did exactly
> what you just suggested).
>
> Oh, and some sites poll responseText from progress events for reasons I
> can't fathom.
>

A number of sites check .responseText.length on every progress event in
order to monitor how much data has been received.  This came up as a
performance hotspot when I was profiling WebKit's XHR implementation as
well.

- James

>
> -Boris
>
>

Received on Tuesday, 28 September 2010 19:06:08 UTC