Last Comment Bug 666104 - Gradual memory increase on test case using setInterval and xmlHttpRequest:
: Gradual memory increase on test case using setInterval and xmlHttpRequest:
Status: RESOLVED FIXED
[MemShrink:P2]
:
Product: Core
Classification: Components
Component: General (show other bugs)
: unspecified
: x86_64 Linux
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 656120
Blocks: mlk-fx5
  Show dependency treegraph
 
Reported: 2011-06-21 20:14 PDT by Nicholas Nethercote [:njn] (on vacation until July 11)
Modified: 2011-06-23 22:00 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Nicholas Nethercote [:njn] (on vacation until July 11) 2011-06-21 20:14:26 PDT
This is a spin off from bug 645633 comment 22;  that bug has become a mess.
Everything below here is quoted from the old bug.


I made some first tests but I definitly will have to do more for a valid statement. 

The website itself shows a different memory alloc-release behavior:
Before in good cases the peaks all have nearly identically shapes, in bad cases the last release phase didn't exist.
Now in good cases even peaks and odd peaks have a different shape but all even looks similar and all odd looks similar. 

But as the bad cases for the site gets less in FF5Beta3, it's still possible that there are some now.

However... here's one of my test-snippets with setInterval and xmlHttpRequest: 

---------
<html>
<head>
<script type="text/javascript">
 function handleStateChange()
    {
        // Do nothing with response whithin this test
    }
    
    
     function myFunc() {
      var xmlHttpObject = new XMLHttpRequest();
        // web service providing an xml response (about 139 Bytes), shouldn't matter in this case
        xmlHttpObject.open('POST', '/some.cgi');
        // 
        xmlHttpObject.onreadystatechange = handleStateChange;
        // send some dummy data.. in my case about 42Bytes
        xmlHttpObject.send(window.document + window.document );
    }
    IntervallId=setInterval("myFunc()",100);
   </script>
</head>
<body>
<p>Test 1</p>
</body>
</html>
-----

Nightly Build started with 30.1 MB. I use the following Snippet and let it run for 15 minutes. The memory then was about 122MB. There was no user interaction in Firefox for this time.

This test site consumed memory in FF4.0.1, FF5Beta3 and Nightly Build (build date 14.Jun).
I don't know the result of FF3.6.x so far.
Comment 1 Nicholas Nethercote [:njn] (on vacation until July 11) 2011-06-21 20:31:32 PDT
Nicole: it's possible that bug 656120 has fixed this problem.  Can you please try a nightly build (nightly.mozilla.org) and let us know if it has been fixed?  Thanks.
Comment 2 nicole.baumann 2011-06-23 00:05:20 PDT
I tested it in Nightly built on 22-Jun-2011.  I did two runs. 

Nightly started with 36 MB.
Here the list of the peaks and the result of the release
1. 	7 min	62 peak	41 after	
2.	5 min   51 peak 41 after
3.	10 min	97 peak	44 after
4.	3 min	64 peak 44 after
5.	9 min   96 peak  44 after
6. 	4 min 	63 peak 45 after
7.      9 min	98 peak 45 after
8.	3 min	65 peak 46 after 
mini peak, after 44 
  
So there seems to be a 4-9-4-9 minute pattern, at least for this page. 
It's definitly much better than before. 

If someone has a explanation for the small memory arise (41 --> 44 MB) or could tell that this isn't correlated with the size of the page / communication-packages, then I would even say, it's solved completely.  

Good work! :-)
Comment 3 Nicholas Nethercote [:njn] (on vacation until July 11) 2011-06-23 22:00:07 PDT
(In reply to comment #2)
> 
> If someone has a explanation for the small memory arise (41 --> 44 MB) or
> could tell that this isn't correlated with the size of the page /
> communication-packages, then I would even say, it's solved completely.  

Heap size measurement tend to be pretty noisy in practice, so 3MB doesn't worry me much.  I'm happy to declare victory here.

Note You need to log in before you can comment on or make changes to this bug.