Loading ...
Sorry, an error occurred while loading the content.

Connection object leaking memory

Expand Messages
  • Troy Wolf
    I have an application with a few dozen pages that all have updating components within the pages. My approach is, I assume, standard: the parent page contains
    Message 1 of 9 , Aug 17, 2006
    • 0 Attachment
      I have an application with a few dozen pages that all have updating
      components within the pages. My approach is, I assume, standard: the
      parent page contains various <DIV>s. I use the connection object
      (AJAX) to go hit another page that returns either JSON objects, XML
      data or HTML content that I then display within the appropriate DIV.
      Many of my modules use javascript's setTimeout() to refresh the data
      every 5 seconds or so using the connection object over and over again
      to make the call for more data.

      We notice a definite pattern in pages that use the connection object
      to frequently update parts of the page where in Firefox, the memory
      usage keeps rising until Firefox is unuseable. The problem does not
      appear in IE6, but now does in IE7.

      I am confident that I'm not doing anything strange with the
      object--using it almost exactly as shown in the documentation
      examples. This problem is serious enough that more people should be
      complaining--this perplexes me. If you have a webpage that uses the
      connection object to frequently update a part of the page and you are
      NOT seeing this issue, please send me a link if your page is publicly
      accessible. I'd love to test it in Firefox and IE7, and if your page
      does not have this problem, I will copy your connection object logic.

      Troy in Kansas City
    • Thomas S. Sha
      ... May I have a look at your code, or preferably a link to the web application? Feel free to email me offline if you don t wish to post the link here on the
      Message 2 of 9 , Aug 17, 2006
      • 0 Attachment
        --- In ydn-javascript@yahoogroups.com, "Troy Wolf" <troy@...> wrote:
        >
        > I have an application with a few dozen pages that all have updating
        > components within the pages. My approach is, I assume, standard: the
        > parent page contains various <DIV>s. I use the connection object
        > (AJAX) to go hit another page that returns either JSON objects, XML
        > data or HTML content that I then display within the appropriate DIV.
        > Many of my modules use javascript's setTimeout() to refresh the data
        > every 5 seconds or so using the connection object over and over again
        > to make the call for more data.
        >
        > We notice a definite pattern in pages that use the connection object
        > to frequently update parts of the page where in Firefox, the memory
        > usage keeps rising until Firefox is unuseable. The problem does not
        > appear in IE6, but now does in IE7.
        >
        > I am confident that I'm not doing anything strange with the
        > object--using it almost exactly as shown in the documentation
        > examples. This problem is serious enough that more people should be
        > complaining--this perplexes me. If you have a webpage that uses the
        > connection object to frequently update a part of the page and you are
        > NOT seeing this issue, please send me a link if your page is publicly
        > accessible. I'd love to test it in Firefox and IE7, and if your page
        > does not have this problem, I will copy your connection object logic.
        >
        > Troy in Kansas City

        May I have a look at your code, or preferably a link to the web
        application? Feel free to email me offline if you don't wish to post
        the link here on the forum.

        Regards,
        Thomas
      • Troy Wolf
        ... Here is a test case. Start your task manager, bring this link up in latest, stable Firefox or IE7, then click the button. Write down how much memory the
        Message 3 of 9 , Aug 18, 2006
        • 0 Attachment
          > May I have a look at your code, or preferably a link to the web
          > application? Feel free to email me offline if you don't wish to post
          > the link here on the forum.
          >
          > Regards,
          > Thomas
          >

          Here is a test case. Start your task manager, bring this link up in
          latest, stable Firefox or IE7, then click the button. Write down how
          much memory the browser is using, then walk away for an hour. When you
          come back, compare the amount of memory used to the starting number.
          http://home.troywolf.com/yuitest1.htm
        • Thomas S. Sha
          ... I m assuming junk.php returns a timestamp, the ~*~ delimiter, and about 34KB string. Testing against yuitest1.htm produces the following: ***** begin test
          Message 4 of 9 , Aug 18, 2006
          • 0 Attachment
            --- In ydn-javascript@yahoogroups.com, "Troy Wolf" <troy@...> wrote:

            > Here is a test case. Start your task manager, bring this link up in
            > latest, stable Firefox or IE7, then click the button. Write down how
            > much memory the browser is using, then walk away for an hour. When you
            > come back, compare the amount of memory used to the starting number.
            > http://home.troywolf.com/yuitest1.htm

            I'm assuming junk.php returns a timestamp, the ~*~ delimiter, and about
            34KB string.

            Testing against yuitest1.htm produces the following:

            ***** begin test *****
            OS: WinXP SP2
            FireFox: versions 1.0.8 and 1.5.0.6
            IE: version 7 beta 3

            In FF, after approximately 10 minutes, the CPU cycles incrementally
            climb. Within 15 to 20 minutes, the CPU will peg at 95+ %, and
            MemUsage/VM size will start climbing rapidly.

            IE 7 beta 3 didn't manifest these conditions.

            FF Initial mem: ~19.3MB
            FF End Memory: ~35.0 MB at time of cancellation
            Duration: 18 minutes

            IE Initial mem: ~20.1MB
            IE End Memory: ~20.3MB
            Duration: 60 minutes
            ***** end test *****

            In reviewing your success handlers, I modified them to set each array
            to "null" after the timestamp has been appended to innerHTML.

            Example:
            function Content1Loaded(o)
            {
            var x = o.responseText.split("~*~");
            document.getElementById('content1').innerHTML = x[0];
            x = null // remove array
            tmr = setTimeout("Content1Load()", 1000);
            }

            ***** begin modified test *****
            OS: WinXP SP2
            FireFox: versions 1.0.8 and 1.5.0.6
            IE: version 7 beta 3

            FF Initial mem: ~20.2MB
            FF End Memory: ~20.5MB
            Duration: 60 minutes

            IE Initial mem: ~20.6MB
            IE End Memory: ~20.7MB
            Duration: 60 minutes
            ***** end modified test *****

            Regards,
            Thomas
          • Troy Wolf
            ... about 34KB string. Yes, exactly what it does. I know one common method is to turn the data into a JSON object server-side, then use client-side code to
            Message 5 of 9 , Aug 22, 2006
            • 0 Attachment
              > I'm assuming junk.php returns a timestamp, the ~*~ delimiter, and
              about 34KB string.

              Yes, exactly what it does. I know one common method is to turn the
              data into a JSON object server-side, then use client-side code to turn
              the JSON object back into an array, but for my needs, a simple, unique
              delimiter seemed easier and more efficient. So typically, I have a
              field or two of metadata, followed by my HTML-formatted content for
              display. In this test case (junk.php), I'm simply returing a large
              string of junk....just to simulate returning significant bytes so my
              test is more like my real-world situation.


              > Testing against yuitest1.htm produces the following:
              >
              > ***** begin test *****
              > OS: WinXP SP2
              > FireFox: versions 1.0.8 and 1.5.0.6
              > IE: version 7 beta 3
              >
              > In FF, after approximately 10 minutes, the CPU cycles incrementally
              > climb. Within 15 to 20 minutes, the CPU will peg at 95+ %, and
              > MemUsage/VM size will start climbing rapidly.
              >
              > IE 7 beta 3 didn't manifest these conditions.
              >
              > FF Initial mem: ~19.3MB
              > FF End Memory: ~35.0 MB at time of cancellation
              > Duration: 18 minutes
              >
              > IE Initial mem: ~20.1MB
              > IE End Memory: ~20.3MB
              > Duration: 60 minutes
              > ***** end test *****
              >
              > In reviewing your success handlers, I modified them to set each array
              > to "null" after the timestamp has been appended to innerHTML.
              >
              > Example:
              > function Content1Loaded(o)
              > {
              > var x = o.responseText.split("~*~");
              > document.getElementById('content1').innerHTML = x[0];
              > x = null // remove array
              > tmr = setTimeout("Content1Load()", 1000);
              > }
              >
              > ***** begin modified test *****
              > OS: WinXP SP2
              > FireFox: versions 1.0.8 and 1.5.0.6
              > IE: version 7 beta 3
              >
              > FF Initial mem: ~20.2MB
              > FF End Memory: ~20.5MB
              > Duration: 60 minutes
              >
              > IE Initial mem: ~20.6MB
              > IE End Memory: ~20.7MB
              > Duration: 60 minutes
              > ***** end modified test *****
              >
              > Regards,
              > Thomas

              Well, I have to admit, I was excited when I first read your reply and
              saw your results. HOWEVER, I modified my test code exactly as you
              show, and I still have the problem. I did not time this exactly, but:

              Firefox version 1.5.06 on WinXP Pro, SP2
              FF Initial mem: ~28MB
              FF End Memory: ~104MB
              Duration: ~30 minutes

              I'm not sure how we could have such different results.
            • Troy Wolf
              I modified the script further by making all variables global so that they all get reused each iteration rather than creating new local variables each time. The
              Message 6 of 9 , Aug 22, 2006
              • 0 Attachment
                I modified the script further by making all variables global so that
                they all get reused each iteration rather than creating new local
                variables each time. The problem still exists:

                FF Initial mem: ~30MB
                FF End mem: ~65MB
                Duration: 30 minutes

                Another pattern I notice is that the memory fluctiation increases the
                more time elapses. For example, at the beginning, the memory used
                bounces between 28MB and 37MB or so. At the end, it is bouncing
                between 57MB and 89MB or so.

                I appreciate the testing you've done. Maybe we'll figure this out.
                Maybe some others have some suggestions.


                --- In ydn-javascript@yahoogroups.com, "Troy Wolf" <troy@...> wrote:
                >
                > > I'm assuming junk.php returns a timestamp, the ~*~ delimiter, and
                > about 34KB string.
                >
                > Yes, exactly what it does. I know one common method is to turn the
                > data into a JSON object server-side, then use client-side code to turn
                > the JSON object back into an array, but for my needs, a simple, unique
                > delimiter seemed easier and more efficient. So typically, I have a
                > field or two of metadata, followed by my HTML-formatted content for
                > display. In this test case (junk.php), I'm simply returing a large
                > string of junk....just to simulate returning significant bytes so my
                > test is more like my real-world situation.
                >
                >
                > > Testing against yuitest1.htm produces the following:
                > >
                > > ***** begin test *****
                > > OS: WinXP SP2
                > > FireFox: versions 1.0.8 and 1.5.0.6
                > > IE: version 7 beta 3
                > >
                > > In FF, after approximately 10 minutes, the CPU cycles incrementally
                > > climb. Within 15 to 20 minutes, the CPU will peg at 95+ %, and
                > > MemUsage/VM size will start climbing rapidly.
                > >
                > > IE 7 beta 3 didn't manifest these conditions.
                > >
                > > FF Initial mem: ~19.3MB
                > > FF End Memory: ~35.0 MB at time of cancellation
                > > Duration: 18 minutes
                > >
                > > IE Initial mem: ~20.1MB
                > > IE End Memory: ~20.3MB
                > > Duration: 60 minutes
                > > ***** end test *****
                > >
                > > In reviewing your success handlers, I modified them to set each array
                > > to "null" after the timestamp has been appended to innerHTML.
                > >
                > > Example:
                > > function Content1Loaded(o)
                > > {
                > > var x = o.responseText.split("~*~");
                > > document.getElementById('content1').innerHTML = x[0];
                > > x = null // remove array
                > > tmr = setTimeout("Content1Load()", 1000);
                > > }
                > >
                > > ***** begin modified test *****
                > > OS: WinXP SP2
                > > FireFox: versions 1.0.8 and 1.5.0.6
                > > IE: version 7 beta 3
                > >
                > > FF Initial mem: ~20.2MB
                > > FF End Memory: ~20.5MB
                > > Duration: 60 minutes
                > >
                > > IE Initial mem: ~20.6MB
                > > IE End Memory: ~20.7MB
                > > Duration: 60 minutes
                > > ***** end modified test *****
                > >
                > > Regards,
                > > Thomas
                >
                > Well, I have to admit, I was excited when I first read your reply and
                > saw your results. HOWEVER, I modified my test code exactly as you
                > show, and I still have the problem. I did not time this exactly, but:
                >
                > Firefox version 1.5.06 on WinXP Pro, SP2
                > FF Initial mem: ~28MB
                > FF End Memory: ~104MB
                > Duration: ~30 minutes
                >
                > I'm not sure how we could have such different results.
                >
              • Thomas S. Sha
                ... May I contact you offline? I d like to provide you with a test build to see if I can isolate this condition. Regards, Thomas
                Message 7 of 9 , Aug 22, 2006
                • 0 Attachment
                  --- In ydn-javascript@yahoogroups.com, "Troy Wolf" <troy@...> wrote:
                  >
                  > I modified the script further by making all variables global so that
                  > they all get reused each iteration rather than creating new local
                  > variables each time. The problem still exists:
                  >
                  > FF Initial mem: ~30MB
                  > FF End mem: ~65MB
                  > Duration: 30 minutes
                  >
                  > Another pattern I notice is that the memory fluctiation increases the
                  > more time elapses. For example, at the beginning, the memory used
                  > bounces between 28MB and 37MB or so. At the end, it is bouncing
                  > between 57MB and 89MB or so.
                  >
                  > I appreciate the testing you've done. Maybe we'll figure this out.
                  > Maybe some others have some suggestions.

                  May I contact you offline? I'd like to provide you with a test build
                  to see if I can isolate this condition.

                  Regards,
                  Thomas
                • Troy Wolf
                  The memory leak issue is not resoloved, but I wanted to follow up here for any of you developers following this thread or searching for YUI memory leak
                  Message 8 of 9 , Aug 28, 2006
                  • 0 Attachment
                    The memory leak issue is not resoloved, but I wanted to follow up here
                    for any of you developers following this thread or searching for YUI
                    memory leak solutions. Thomas is helping me figure out the memory leak
                    problems. He provided a test build that in my initial tests did not
                    appear to help. Then, I fixed some small errors in my test
                    implementation, and found that the test build did not leak memory
                    while the production build continues to leak memory. So I have a
                    glimmer of hope on the horizon now. I'll follow up here with more
                    information as it becomes available.
                  • Troy Wolf
                    OK, the problem seems to be gone now. As of yui release 0.11.3, my test page no longer leaks memory. I looked through the general release notes as well as the
                    Message 9 of 9 , Aug 31, 2006
                    • 0 Attachment
                      OK, the problem seems to be gone now. As of yui release 0.11.3, my
                      test page no longer leaks memory. I looked through the general release
                      notes as well as the connection object release notes and nothing about
                      fixing memory leaks is mentioned, but my tests show the problem has
                      been corrected.
                    Your message has been successfully submitted and would be delivered to recipients shortly.