- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 27 Oct 2010 03:50:36 -0400
- To: Boris Zbarsky <bzbarsky@mit.edu>
- CC: Darin Fisher <darin@chromium.org>, Chris Rogers <crogers@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Anne van Kesteren <annevk@opera.com>, Eric Uhrhane <ericu@google.com>, michaeln@google.com, Alexey Proskuryakov <ap@webkit.org>, Chris Marrin <cmarrin@apple.com>, Geoffrey Garen <ggaren@apple.com>, jorlow@google.com, jamesr@chromium.org
On 10/27/10 3:40 AM, Boris Zbarsky wrote: > On 10/27/10 3:24 AM, Darin Fisher wrote: >> So, it sounds like we just need to present you with some concrete >> examples of XHRs being used to fetch large responses as Text or XML, and >> then you will be convinced? > > Uh... no. I'm sure these happen. The question is whether their existence > is sufficient grounds to impose additional burdens on other uses of XHR. And specifically for the case you cited (large XML file that you process via XML) Webkit is already storing two copies of the data: the responseText and the parsed DOM. I'd be very surprised if the latter is much smaller in terms of memory used, and somewhat surprised if it's smaller at all. So for this specific use case, in fact, if you just stored the raw bytes and the parsed DOM you would be no worse off than you are now (and this is in fact what Gecko does in this situation). The double storage issue really only comes up for cases when responseText is being used, not responseXML, as far as I can tell. -Boris
Received on Wednesday, 27 October 2010 07:51:47 UTC