I'm experincing browser memory leaks while using Kendo UI DataWiz charts.
Basically, I use
.kendoChart(data)
kendo.destroy()
Here's a test page that inits and destroys 50 charts for 10 times every 2 seconds (I attached full sources):
<
html
>
<
head
>
<
script
src
=
"js/jquery-1.8.2.min.js"
></
script
>
<
script
src
=
"js/kendo.dataviz.min.js"
></
script
>
<
script
>
var data = {
theme: $(document).data("kendoSkin") || "default",
title: {
text: "Internet Users"
},
legend: {
position: "bottom"
},
chartArea: {
background: ""
},
seriesDefaults: {
type: "bar"
},
series: [{
name: "World",
data: [15.7, 16.7, 20, 23.5, 26.6]
}, {
name: "United States",
data: [67.96, 68.93, 75, 74, 78]
}],
valueAxis: {
labels: {
format: "{0}%"
}
},
categoryAxis: {
categories: [2005, 2006, 2007, 2008, 2009]
},
tooltip: {
visible: true,
format: "{0}%"
}
};
$(document).ready(function() {
window.iteration = 0;
window.of = 10;
$('input').on('click', function() {
refreshCharts();
$(this).hide();
$('p.iteration').html('Starting...');
return false;
});
});
function refreshCharts() {
setTimeout(function() {
removeCharts();
addCharts();
window.iteration++;
$('p.iteration').html('Iteration: ' + window.iteration + ' of ' + window.of);
if (window.iteration <
window.of
) {
refreshCharts();
} else {
$('p.iteration').html('Completed');
}
}, 2000);
}
function addCharts() {
for (var
i
=
0
; i < 50; i++) {
addChart();
}
}
function addChart() {
$('<div></
div
>')
.addClass('chart')
.css({'float': 'left', 'clear': 'both', 'width': '400', 'height': '400', 'background-color': '#fff', 'margin': '2px'})
.appendTo($('div.content'))
.kendoChart(data);
}
function removeCharts() {
$('div.chart').each(function() {
kendo.destroy($(this));
$(this).remove();
});
}
</
script
>
</
head
>
<
body
>
<
p
>KENDO UI</
p
>
<
p
class
=
"iteration"
></
p
>
<
p
><
input
type
=
"button"
value
=
"Start"
/></
p
>
<
div
class
=
"content"
></
div
>
</
body
>
</
html
>
Please confirm that the way the memory is freed is correct, or maybe there's something I'm missing regarding the API.
Did you by chance make any improvement regarding memory management in current BETAs?
Thanks
25 Answers, 1 is accepted
Thank you for taking the time to identify this problem and build a test page.
I've traced the problem down to an undisposed field. The fix will be included in the next internal build scheduled for the following week. It can also be applied directly on the page:
var destroy = kendo.UserEvents.fn.destroy;
kendo.UserEvents.fn.destroy = function() {
destroy.call(this);
this.unbind();
}
As a token of gratitude for your involvement your Telerik points have been updated.
Tsvetomir Tsonev
the Telerik team

-- Keith
Did you try the 2012.3.1323 internal build? It contains a number of bug fixes and a simple upgrade might be sufficient.
We'll appreciate a test page if the problem persists.
Tsvetomir Tsonev
the Telerik team

At first, I was puzzled and did not know where to find the latest beta release. I eventually figured it out by logging into my Telerik account.
1. Yes, I have download 2012.3.1323. The only file copied to ICENIUM was kendo.dataviz.min.js
2. The memory leak can easily be tested in the examples\dataviz\api\benchmark.html. Launch the Task Manager and you can quickly see the memory leak go from 55MB to 100+MB in minutes.
3. The beta release 2012.3.1323 appears to have solved the memory leak issue. I need to test the application further / long term.
Do let me know if there is anything else I need to do.
Thank you for your help and support.
Regards,
Keith
Yes, updating should be sufficient. Future versions will also contain this fix.
Apologies for the caused inconvenience.
Tsvetomir Tsonev
the Telerik team

1. Testing is ongoing... so its too early to tell if memory is leaking over the long term. The good news is that the application is running a lot longer than a few hours both on ICENIUM and a Samsung Android tablet! In the interim...
2. What I found is that you must call kendo.destroy($("#XYZchart")); after up dating the data to the chart else the memory leak persists. The side effect is that Tool Tips are not displayed when you place the mouse over a column or bar. A solution is to display the value labels as shown in the attachment on the first two charts. However, when you have a high number of data points, its not going to look good on the chart with 1000+ data points.
I tried to set a timer to call the destroy() function after a few minutes but the memory leak continued and the destroy() must be called after each data update.
Can you advise on a solution moving forward on how to display the tool tips?
Thank you,
Keith

I am sorry to report that the memory leak while reduced still continues when kendo column / bar charts are used in the application using the 2012.3.1323 version.
Please provide an alternate solution.
Regards,
Keith
We investigated the issue and came up with some interesting results.
We observed a memory leak in Chrome that seems to affect inline SVG in general. It wasn't there a few releases back. We'll submit a bug report and try to work around it in the meantime.
Memory usage in Firefox, IE and iOS seems stable and didn't require an explicit call to destroy.
Can you please share a sample of the update code that you're using? We might be missing something in our tests.
Tsvetomir Tsonev
the Telerik team

1. I do not agree with your statement that under IE, the memory is stable. I have not checked FireFox or iOS.
2. Currently, I am only developing and testing in ICENIUM. However, you can confirm the leak in IE based on your own example: kendoui.dataviz.2012.3.1323.commercial\examples\dataviz\api\benchmark.html
Please see attached image.
Regards,
Keith
I must have messed up my test case while looking at the IE memory usage. Sorry about that.
I'm not worried about the particular amount of used memory, as browsers will typically delay garbage collection as much as possible. But the usage seems to grow rapidly and we're investigating the possible causes.
So far we've spotted one static cache that never gets cleared. We'll fix this and let it run overnight to see if that helps.
Thank you for your patience.
All the best,
the Telerik team
Just wanted to let you know that we're making good progress with this issue.
The root cause turned out to be a very nasty bug in IE. It will leak memory each time you render an element with unique ID. Here are two standalone demonstrations of this issue:
It seems to be a fresh discovery, as we're among the first to stumble in it. It affects all IE versions including 10.
Working around this had great effect on the memory usage. We're now performing some more testing and we'll upload an internal build early next week.
Thank you for your patience.
Kind regards,
Tsvetomir Tsonev
the Telerik team
We've uploaded an internal build (2012.3.1412) that should behave much better in terms of memory usage in IE and others.
Please, feel free to give it a try when you have the chance.
Tsvetomir Tsonev
the Telerik team

I am sorry to inform you that the latest build 2012.3.1412 has not resolved the memory leak issue.
The reason I can confirm this is that when I comment updating the kendo charts, I do not see any memory leak.
Regards,
Keith
Indeed, the leaks are still here. But should be much less severe. I apologize for setting the wrong expectations by not clarifying.
They are caused by two bugs in IE and are not related to the Chart in any way. All tested versions of IE seem to be affected with the exception of IE10 on Windows 8.
- Bug #1 - Leaking element IDs (idleak.html)
- Bug #2 - Leaking object properties (hashleak.html)
We have reported this problems directly to Microsoft and we hope for a timely fix.
In the meantime, we've managed to workaround bug #1. This is what is contained in the 2012.3.1412 internal build.
Bug #2 is more problematic, as it affects much more use cases. We don't have and can't possibly have complete solution for it, but we tried to reduce its impact. We'll upload yet another build later today (2012.3.1413) that further reduces the memory usage.
Please, keep in mind that the "benchmark demo" page is stressing the browser as much as possible. A real-world chart with an update every few seconds will survive at least a full day.
Tsvetomir Tsonev
the Telerik team

1. Thank you for the detailed response and attention. Understood! - IE issues are out of your control.
2. We have therefore, decided to concentrate initial deployment for a single platform - Android tablet and are using ICENIUM as the IDE. Deployment to a Samsung tablet using Cordova 2.2.0 and OS version 4.2. We would like to update the charts every 1 second and are seeing the memory leak and the application crashes within 24 hours.
3. Our target release date is around March 15th. We definitely need to know if this memory leak can be / will be resolved within the next 2 weeks. If not, we have no choice but to look at alternative options for charting.
Sincerely,
Keith
Frankly, 24 hours is very respectable endurance for the built-in WebView in Android. It uses the built-in browser engine and not Chrome/V8. Such prolonged execution period will amplify even minor leaks in every subsystem, from the drivers to the JS engine. Heap fragmentation can also have a significant role.
Perhaps calling reload() every now and then will help. Is that an option?
With this in mind, we can't commit with a fix in the specified time frame. We'll try to identify the obvious memory leaks, but it's likely that we won't find many, if at all. There's only so much we can do from our position as web developers. We're constantly reminded that problems in the platform itself are outside of our control.
Tsvetomir Tsonev
the Telerik team

i am watching this thread since end of january cause we are experiencing similar memory problems with IE and datawiz-api.
i stripped down an example out of our application to a "simple" html-file.
Attached to this post you can find the example. we tested with 3 different versions of kendo. I removed the sources/styles of kendo to pass the upload limit ;-)
Just add kendo-sources/styles (not the minimized ones) and press the "REFRESH"-Button at the top of the page
For reloading the charts we use the following code-snipped...
kendo.destroy($("#wfms_dashboard_ordertype"));
$("#wfms_dashboard_ordertype").empty();
After this we initialize a new chart within the <div>.
We tested with IE8 and IE9.
Test 1:
Kendo 2012.3.1114 (currently used in our production environment of our application)
Memory-Issue: Medium, but at the end of the day ie8 crashes with memory problemes, cause dashboard is reloaded every 60 seconds.
Test 2:
Kendo 2012.3.1315 (Seems to be the current stable release of kendo)
Memory-Issue: Big (do not know why it looks worse than release of Test 1)
Test 3:
Kendo: 2012.3.1413 (your current internal release)
Memory-Issue: Smaller, but not gone
Maybe this example is helpful for terminating the issue.
Thanks in advance.
Tobias
We conducting more tests and I'm sharing our observations so far.
- IE is leaking memory in the form of internal structures, not JS heap. This leads to rapidly degrading memory allocation performance.
- The SVG renderer seems to be worse in this respect. Switching to VML rendering improves it at the cost of some memory:
- Turning off animations (transitions: false) improves stability
The VML renderer can be selected by executing this snippet before initializing the chart:
kendo.dataviz.SVGView.available = function() { return false; };
Note that calling kendo.destroy is required whenever a widget is removed from the page. This behavior is by design.
We're experimenting with few new ideas that look promising. Hopefully, we'll be able to move them into production soon.
Thank you for your patience.
Tsvetomir Tsonev
the Telerik team

setInterval(function() {
var ds = kChart.dataSource,
length = ds.total();
for (var i = 0; i < length; i++) {
ds.at(i).set('value', Math.floor((Math.random()*100)+1));
}
}, 1000);
And then use some Task Manager tool and observe the memory increase monotomically. I've had it running for ~10 minutes and the Chrome Chrome Renderer is at 350M already.
Anything I can do about this? Our application is an Enterprise monitoring and management tool, so this is something that must be able to run indefinitely.

I also assigned window.kChart in createChart.
I've experienced this in all Kendo versions I've tried. Currently using 2012.3.1512.
The leak you're experiencing is caused by a bug in Chrome. It's triggered by rendering any SVG on the page. See this jsBin for example.
On a positive note, this bug is fixed in Chrome version 26 (currently beta). It should hit the stable channel within 6 weeks. Switching to the beta channel is the only solution for the time being.
I'd also like to share that we did a number of changes for the upcoming Q1 release and the leaks in IE are pretty much cured. We still have problems related to heap fragmentation, but they are a lesser evil by far.
Tsvetomir Tsonev
the Telerik team

I see the same problem with Firefix 19.0.2. Is that because it's based on the same rendering engine as Chrome? With Safari I see memory increasing significantly but it appears to be properly reclaimed.
Gary
Terracotta
Memory usage in Firefox is improved in Q1, but it was OK to begin with. Do you, by chance, have Firebug turned on? It might be causing excessive memory usage.
Greetings,Tsvetomir Tsonev
the Telerik team

All users that are experiencing memory leaks are urged to upgrade to the Q1 '2013 release.
Please, open a new thread for any outstanding issues.
Tsvetomir Tsonev
the Telerik team