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

UNCONFIRMED
Unassigned

Status

()

Core
DOM
UNCONFIRMED
9 years ago
9 years ago

People

(Reporter: claude.vervoort, Unassigned)

Tracking

Trunk
x86
Windows Server 2003
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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

9 years ago
I don't see the test case.
(Reporter)

Comment 2

9 years ago
Created attachment 336921 [details]
test files to repeat the issue

removed prototype 1.6 library to fit within space requirement

Comment 3

9 years ago
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.
(Reporter)

Comment 4

9 years ago
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();
    }
  },
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk

Comment 5

9 years ago
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

Updated

9 years ago
Duplicate of this bug: 483503

Comment 7

9 years ago
I've been having a similar issue with Seamonkey.  See Bug 483503 for details on what I ran into.
You need to log in before you can comment on or make changes to this bug.