453709 - Ajax Call: Huge Memory Spike when requesting large data set, sometimes resulting in an empty responseText

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P5)

Description

[claude.vervoort]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

When the response to an Ajax Request is large (2.5mo of JSON text), Firefox has a huge but brief spike in memory usage (up 1.5 Go!). As a result the actual responseText ends up sometimes/often being empty.

I see no similar spike in IE7 and Chrome.

Reproducible: Always

Steps to Reproduce:
I've uploaded a set of test files to repeat it. Deploy on some web server to use it and just access test.html. It will send an Ajax request to get the big payload file.

Note that you may need to fix some of the URLs in test.html depending on where you deploy the files.
Actual Results:  
Depending on how lucky you are, the response is properly loaded or not. In both case, there is a huge but short memory spike.

Expected Results:  
Well the data is always loaded...

Comment 1

[Robert Sayre]

I don't see the test case.

Comment 2

[claude.vervoort]

Attachment: test files to repeat the issue

removed prototype 1.6 library to fit within space requirement

Comment 3

[Mark Omohundro]

Interesting one.  Ran your test myself and got the following results:

your test app/your test data using Prototype 1.6.0.2:
Firefox 3.0.1  test file did not finish loading (even once)
Opera 9.52     successful
IE6            successful

my test app/your test data using my own AJAX library:
Firefox 3.0.1  successful
Opera 9.52     successful
IE6            successful

and the test file worked with FF in my lib's test even though more memory appeared to be consumed (just loaded your test file with my own larger test app, but there could be other differences). curious, huh?  could still be a FF memory issue though, difficult to tell.  but hope this feedback helps.

Comment 4

[claude.vervoort]

That helped! I've narrowed to one line of code: firefox sends a lot of ready state 3 (receiving). Prototype creates a response object for each one of those and get a copy of the current response text in it. So it looks like it is the repeated access to the growing responseText to be the cause, even if you do nothing with that string. Somehow accessing this object over and over is creating the memory spike. If I just access when the readyState is complete then all seems fine.

Ajax.Response = Class.create({
  initialize: function(request){
    this.request = request;
    var transport  = this.transport  = request.transport,
        readyState = this.readyState = transport.readyState;

    if((readyState > 2 && !Prototype.Browser.IE) || readyState == 4) {
      this.status       = this.getStatus();
      this.statusText   = this.getStatusText();
      // original line: 
      // this.responseText = String.interpret(transport.responseText);
      //
      // still seeing the huge memory spike with only:
      // transport.responseText;
      // 
      // not seeing it here
      // if ( readyState > 3 ) this.responseText = String.interpret(transport.responseText);
      this.headerJSON   = this._getHeaderJSON();
    }

    if(readyState == 4) {
      var xml = transport.responseXML;
      this.responseXML  = Object.isUndefined(xml) ? null : xml;
      this.responseJSON = this._getResponseJSON();
    }
  },

Comment 5

[Mark Omohundro]

Claude, glad to help.  I do something similar at the top of my AJAX callback function which might explain why I didn't have the file loading problem either:

if (!xhrResponse || xhrResponse.readyState < 4) {
  return;
}

This can also speed up the overall processing (to return immediately) since at
times the callback routine fires a number of times -- and in other browsers I have tried -- before readyState reaches stateComplete, as you noticed and mentioned.  That's why I did the above to begin with anyway.

Let's hope the Firefox braintrust/demigods/experts/gurus can take it from here
if any fix is needed. :))

Regards,
Mark

Comment 7

[dr2867.business]

I've been having a similar issue with Seamonkey.  See Bug 483503 for details on what I ran into.

Comment 8

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.