Firefox memory issue...

DaveR · Post by **DaveR** » Wed Mar 12, 2014 2:43 pm

We have used the .Net version of TeeChart for years. Great product! We are now evaluating the HTML5 chart control. We can create the chart, update it dynamically from websockets, etc. On IE and Chrome it runs fine. On Firefox we see the associated memory go up, up, up, until it finally blows up. Have you seen anything like this on your end? Is there anything special we need to do for Firefox?

Post by **Yeray** » Thu Mar 13, 2014 12:03 pm

Hi Dave,

With the code below, I've seen in the Task Manager Firefox seems to take more memory while I drag the chart around, scrolling the chart, zooming and unzooming. However, if do nothing, after a while Firefox seems to restore the initial amount of memory on demand.

Code: Select all

<!DOCTYPE html>
<html>
<head>
<title>Testing</title>

<!--[if lt IE 9]>
    <script src="../src/excanvas/excanvas_text.js"></script>
    <script src="../src/excanvas/canvas.text.js"></script>
<![endif]-->

<script src="../src/teechart.js" type="text/javascript"></script>
<script src="../src/teechart-extras.js" type="text/javascript"></script>

<script type="text/javascript">

var Chart1;

function draw() {
  Chart1=new Tee.Chart("canvas1");
  
  s = new Tee.PointXY().addRandom();
  Chart1.addSeries(s);
  
  Chart1.draw();
}
  
</script>
</head>
<body onload="draw()">
<br><canvas id="canvas1" width="600" height="400">
This browser does not seem to support HTML5 Canvas.
</canvas>
<br>

</body>
</html>

Is this what you are reporting? If not, can you please arrange a simple example we can run as-is to reproduce the problem here?

Thanks in advance.

DaveR · Post by **DaveR** » Thu Mar 13, 2014 1:32 pm

Sorry, no. The issue I am referring to is different. If I fire up a chart in Firefox, memory usage will begin to grow. Once or twice you might see garbage collection come along and reduce the amount of memory used. Within a couple minutes, however, the memory used will exceed available resources and things blow.

I can send a link to you with instructions on how to run the chart. I think you can even see the code. Is there a preferred address to which I should send the link privately?

This might be a little different than you have encountered before. We have successfully linked the chart running inside the browser to a live data feed via HTML5 web sockets. This chart is getting much more data than most would be feeding to it.

DaveR · Post by **DaveR** » Thu Mar 13, 2014 2:14 pm

Bad news on providing a link for you. Apparently this project is only visible inside our company network.

The developer on this project tells me he has some code where he has a timer updating the chart with random data, which produces similar results on firefox. I will see if I can get that project to you.

DaveR · Post by **DaveR** » Thu Mar 13, 2014 8:13 pm

I am attaching a small code project. It consists mostly of your sample code for adding new data to the control. It also contains a timer that fires once each second, and which populates an additional 100 data points with each tick. If you run it on IE or Chrome, it will run all day with no problems. If you run it on Firefox you are apt to see Garbage Collection occur one time and then memory will be consumed until it blows up.

The sample project is from VS2012, and was written in C#. Please let me know if we are coding something incorrectly, or if there is something you can fix on your end.

Hoping to be a happy customer, for a second time!

Dave

Post by **Marc** » Mon Mar 17, 2014 4:31 pm

Hello Dave,

Thanks for sending the sample project. Yes, it seems comes down to Firefox's ability to handle the amount of data going in and the array modifications taking place. It may depend on the machine as to how much data can be loaded.

If it isn't necessary to keep all of the historical data in the chart then the best idea may be to delete data from the beginning of the chart datasets as data is added to the end ("first-in-first-out").

For example, applying that to your code sample:

Code: Select all

        var counter = 1;
        var repaints = 0;

        function draw() {

            repaints = repaints + 1;

            ohlc.add = function (open, close, high, low) {
                var d = this.data;
                var count;

                if (d.open) count = d.open.length + 1; else count = 1;
                d.values.length = count;
                d.close = d.values;

                if (d.open) d.open.length = count; else d.open = new Array(1);
                if (d.close) d.close.length = count; else d.close = new Array(1);
                if (d.high) d.high.length = count; else d.high = new Array(1);
                if (d.low) d.low.length = count; else d.low = new Array(1);

                d.open[count - 1] = open;
                d.close[count - 1] = close;
                d.high[count - 1] = high;
                d.low[count - 1] = low;
                counter = counter + 1;
            }

            for (var i = 0; i < 100; i++) {
                var o = 25 + Math.random() * 100;
                var c = o + (Math.random() * 25) - 12.5;
                ohlc.add(o, c, Math.max(o, c) + Math.random() * 15, Math.min(o, c) - Math.random() * 15);

            }

            if ((ohlc.count()) > 150)
            {
                for (var i = 0; i < 50; i++) {
                    ohlc.data.open.shift();
                    ohlc.data.high.shift();
                    ohlc.data.low.shift();
                    ohlc.data.close.shift();
                    ohlc.add
                }
            }

            Chart1.title.text = "Repaints: " + repaints;
            //Chart1.axes.bottom.scroll(50);
            Chart1.axes.bottom.setMinMax(ohlc.count() - 100, ohlc.count());
            Chart1.draw();
        }

Regards,
Marc Meumann

Post by **Marc** » Mon Mar 17, 2014 5:07 pm

... small correction to that code. The delete loop should be taking 100 values out:

Code: Select all

            if ((ohlc.count()) > 200)
            {
                for (var i = 0; i < 100; i++) {
                    ohlc.data.open.shift();
                    ohlc.data.high.shift();
                    ohlc.data.low.shift();
                    ohlc.data.close.shift();
                    ohlc.add
                }
            }

Added labels too, as using index on bottom axis loses overall count.

when adding:

Code: Select all

d.labels[count - 1] = "idx " + counter; //in test integer alone fails ..bug to fix, probably best anyway with timestamp here

when removing

Code: Select all

ohlc.data.labels.shift();

Regards,
Marc

DaveR · Post by **DaveR** » Mon Mar 17, 2014 7:26 pm

I think we are not yet at the root of this problem. The issue is not add a new bar/remove an old bar. The issue has to do with redrawing the existing chart.

I have attached a new little test project. This one will draw a chart with 500 random bars on it. Then it has a timer that will update only the last bar with new data. (No new bars are added.) When run in Firefox the memory usage will immediately begin increasing. It will go to a point where it finally blows things up.

We started with a project that had one bar and updated that bar the exact same way. With a single bar on the chart, system memory appears to be managed OK and the chart does not blow out. Only when you add bars to the chart and then attempt the updates does it fail. This would make it seem that the memory issue is related to the redrawing of existing bars with each update.

Any thoughts?

Thanks!

Post by **Marc** » Tue Mar 18, 2014 12:35 pm

You might have answered your own question when setting the timeout interval to 50msec to more adequately show the error. Firefox isn't reacting quickly enough and the timer isn't asynchronously waiting for work to finish before it goes for it again.

Put in a repaint counter (my code that changes the title in the last post) and you'll see the the chart starts counting paints one by one (all good), 1,2,3,4...etc (if it locks too quickly at 50msec, try 500msec to test the principle) . But then when Firefox becomes busier, perhaps first falling behind when trying to process its first garbage collection, the paint intervals jump 18, 21,26,...etc (not good). That shows that the code cycle is being entered into but that the repaint hasn't taken place for the cycles shown by the 'jump-interval' that's being shown up between browser chart title changes. As the test progresses you'll see jump (real paint) intervals at more than 50 ..and so forth.

You could slow the timer to a modest level that guarantees time on all machine-browser combinations or you could give the control back to the paint-cycle by putting the timer back into it (preferred option I would say).

ie. Remove the worker and:

Code: Select all

function draw() {
   do work.....
   Chart1.draw();

   setTimeout("draw()", 50);
}

function startChart() {
    Chart1 = new Tee.Chart("canvas");
    Chart1.title.text = "Candle OHLC";

    ohlc = new Tee.Candle();
    Chart1.addSeries(ohlc);

    setTimeout("draw()", 50);
}

If you want to make guarantees for realtime cycling to reflect a true-to-lifetime data cycle, I suggest that both methods (external/internal timer) would require a timestamp regulator anyway (...as all browser environments are subject to external factors that affect timecycle fidelity).

Regards,
Marc

DaveR · Post by **DaveR** » Tue Mar 18, 2014 4:21 pm

Are you suggesting that waiting for "Chart1.draw()" to return and then starting the timer again will control this issue? If so, that would be a very simple solution.

Post by **Marc** » Wed Mar 19, 2014 9:02 am

Yes, if you run it as in the code snippet of my last post you should see the difference. It worked here and shows the correct repaint sequence at all times, including after the slight lag that takes place from time whilst Firefox handles other processes (garbage collection, etc).

Regards,
Marc

Firefox memory issue...

Firefox memory issue...

Re: Firefox memory issue...

Re: Firefox memory issue...

Re: Firefox memory issue...

Re: Firefox memory issue...

Re: Firefox memory issue...

Re: Firefox memory issue...

Re: Firefox memory issue...

Re: Firefox memory issue...

Re: Firefox memory issue...

Re: Firefox memory issue...

	Yeray Alonso Development & Support Steema Software Av. Montilivi 33, 17003 Girona, Catalonia (SP)
	Please read our Bug Fixing Policy