I have struggled around with the heap profiler in chrome but it is very confusing. Especially if there are minimized libraries inside. But even the DOMElements views, elements which may not be removed are very unclear presented.
Are there any tips how to use the heap dump in chrome to find JS code that leads to memory leaks, code that cannot be cleaned by GC... and how to find elements messing around even if removed from dom?
In other words, how to read heap dump in chrome correctly? Dominators View? Comparison?
Chrome now offers much better tools to find memory leaks, than at the time of most answers.
Here is to find memory leaks in javascript with a recent Chrome browser:
Press F12 to open the developer tools and go to the Memory Tab.
Pick a feature or a part of your app that you want to inspect for leaks. For example, when a dialog is opened and closed again, the memory used by it should be released.
Do the action (for example opening a dialog) you want to check for memory leaks once, so potential global services can be loaded. This prevents these objects, that are intentionally preserved from showing up as leaks.
Now select Record Allocation Timeline and press Start. Repeat the action you want to check for leaks a few times. So for example open a dialog, close it and repeat. While you do this Chrome draws the timeline with partially grey or blue bars. Usually you see a bar for each time you performed the action on your page. When the bar from several previous iterations of the action stays partially blue it usually means there is a memory leak. The blue part of the bar represents memory that was allocated at this time and has not yet been released again. Stop the recording by pressing the red dot on the top left of the developer tools.
When you see potential leaks you have to inspect this part of the timeline to find the source. Select a part of the timeline that is a few iterations of your actions in the past. And Chrome will show a list of object-types that are still present in the memory. The retained size column gives you an impression how much memory is still used. Browse into one of the object-types and select an object. If you do that, the list of retainers will appear below.
The list of retainers shows the "parent" objects that reference the selected object. Now you need to look at the retainers and your code to understand why the memory has not been released. For example in the image you see the object of the type scope. The second line says the scope is "context in initFormat()". The problem was that initFormat was an event listener that was not unbound after a dialog was left.
After you fixed your code check if the problem has been solved. Refresh the page and repeat the steps 3 to 6 again. If you have never checked for memory leaks before it is not unlikely that you find multiple problems.
Additional hints:
Sometimes there are caches that retain a part of the memory. Usually you can ignore them.
When you see the HTMLDivElement or other DOM elements in the list of object-types have a look. If the objects in this list are highlighted red it means they are no longer present in your page. This means they must be reference somewhere in the code. You may have forgotten to unbind an event listener.
Read about memory leaks in general, so you can identify them quicker in your code.
In Chrome developer tools, there is a Timeline - Memory tab:
We can watch the memory occupied by it.
There is also Profiles - Memory, where we can take a snapshot and see what’s inside. Snapshots can be compared to each other:
Most of time, it doesn’t tell you anything. But at least you can see which objects are piling up, and probably the structure of the leak.
Other way is using 'Task Manager'
here is an article regarding this:
http://www.javascriptkit.com/javatutors/closuresleak/
Google open sourced a tool for this purpose, leak-finder-for-javascript. They also proposed a method so-called the three snapshot technique (also see a brief description in this article).
First paragraph of the leak-finder link
Note: jsleakcheck is no longer supported! It was working against an unofficial and unstable Dev Tools protocol for taking heap snapshots.
The protocol is being worked on, and it is not stable enough so that I
could keep jsleakcheck working with various Chrome versions. In
addition, a lower level compatibility tool,
remote_inspector_client.py, which jsleakcheck was using to communicate
with Dev Tools, got removed.
I found this article very insightful:
http://addyosmani.com/blog/taming-the-unicorn-easing-javascript-memory-profiling-in-devtools/
It does cover the chrome developer tools extensively and explains very well how to go about when your application seems to have memory issues.
Quoted from JavaScript Kit:
If you are developing client-side re-usable scripting objects, sooner or later you will find yourself spotting out memory leaks. Chances are that your browser will suck memory like a sponge and you will hardly be able to find a reason why your lovely DHTML navigation's responsiveness decreases severely after visiting a couple of pages within your site.
A Microsoft developer Justin Rogers has described IE leak patterns in his excellent article (from web.archive.org).
In this article, we will review those patterns from a slightly different perspective and support it with diagrams and memory utilization graphs. We will also introduce several subtler leak scenarios. Before we begin, I strongly recommend you to read that article if you have not already read.
Why does the memory leak?
The problem of memory leakage is not just limited to Internet Explorer. Almost any browser (including but not limited to Mozilla, Netscape and Opera) will leak memory if you provide adequate conditions (and it is not that hard to do so, as we will see shortly). But (in my humble opinion, ymmv etc.) Internet Explorer is the king of leakers.
Don't get me wrong. I do not belong to the crowd yelling "Hey IE has memory leaks, checkout this new tool [link-to-tool] and see for yourself". Let us discuss how crappy Internet Explorer is and cover up all the flaws in other browsers".
Each browser has its own strengths and weaknesses. For instance, Mozilla consumes too much of memory at initial boot, it is not good in string and array operations; Opera may crash if you write a ridiculously complex DHTML script which confuses its rendering engine.
Although we will be focusing on the memory leaking situations in Internet Explorer, this discussion is equally applicable to other browsers.
continue reading...
Here is a very good post about how to find memory leaks using the Google Developper Tools: http://gent.ilcore.com/2011/08/finding-memory-leaks.html
Here is another good web page about that : http://javascript.crockford.com/memory/leak.html
I don't see mentioned window.performance.memory, which gives you the run-time ability to monitor and take action based on memory usage.
window.performance.memory:
MemoryInfo {
totalJSHeapSize: 7084834,
usedJSHeapSize: 6486770,
jsHeapSizeLimit: 4294705152
}
For a handy percentage, use this:
window.performance.memory.usedJSHeapSize / window.performance.memory.jsHeapSizeLimit
https://developer.mozilla.org/en-US/docs/Web/API/Performance/memory
Related
I am developing a voxel engine in Javascript using Threejs, and I've run into some memory usage problems. The intended environment is within an Electron application, which means I can launch the program with flags (--expose-gc) that enable manual garbage collection with gc().
I noticed that when running the gc() function, much less memory was freed compared to when I clicked the "collect garbage" button in the Memory section of Chrome's developer tools. For example, if the program initially used 2000 MB of memory, after gc() it would free up to 300 MB, but after clicking the aforementioned button, it would free up to 600 MB more, making it about half of what it originally was.
After some digging, I also found out about the --gc-global flag. This would've been perfect, since it behaved in the same way as a manual gc did, but it ran multiple times per second, making my program extremely laggy. I tried controlling the gc rate with --gc-interval, but it didn't affect it at all.
I also found this answer that talked about ProfilerAgent.collectGarbage();, but it always threw a reference error. Additionally, the flag it provided (--debug-devtools-frontend) wasn't recognised by Chrome. That, and the fact that I could find very little info on it outside of the answer, lead me to believe that it's an obsolete feature.
I also profiled the memory usage from the developer tools, and surprisingly, it was much lower compared to the value that Task Manager showed me: it seemed to be unaffected by the leaking memory. This has made it nearly impossible to determine where the memory could be leaking from.
I should also make it clear that while Chrome does garbage-collect on its own, it's far too infrequent, and it rarely does a full gc, meaning that memory usage is about twice of what it could be.
In summary, is there a way to trigger a full garbage collection from either Chrome or nodejs/Electron? Obviously, I'm not concerned about cross-browser support, so any advice would be appreciated.
It turns out that self.gc only collects garbage in the thread/worker it was called from. Running the function in all of my workers freed as much memory as the developer tools garbage collector did.
I suspect my one-page javascript app contains a memory leak somewhere. Weak devices running Firefox or Chrome seem to crash eventually if the page is left open. I'm trying to determine whether reloading the page would be expected to free the memory or not.
I understand that memory handling is specific to the browser, so the answer may differ in Chrome or Firefox.
NOTE: I recognize that browsers are mentioned a lot in this question (which would be off topic), but the point of this question is about javascript debugging, which I think is very on topic.
Barring browser/extension bug, browsers free up resources when they are no longer needed; Firefox clears compartments, Chrome kills processes and associated storage.
Firefox does its best but may take some time to clear the memory and may create zombie compartments on occasion:
Compartments are destroyed when they are garbage collected. This happens some time after the last reference to them disappears. This means there can be a delay between a page being closed and its compartments disappearing...
Sometimes, due to bugs in Firefox, the Add-on SDK and/or add-ons, compartments are created that are never destroyed. These are a particular kind of memory leak, and they cause Firefox's memory usage to increase gradually over time, slowing it down and making it more likely to crash.
Chrome uses a process per tab (and really subprocesses for some entities within a tab as well IIRC e.g. plugins, iframes, etc.) to the same effect. Though a quick check against chrome://memory-redirect/ and refreshing a tab looks like the same pid is used. So a refresh is not a completely clean slate.
FWIW Chrome has a "Force Reload" that clears the cache and might be either useful for clearing more memory or a placebo: cmd-shift-r
I'm not really familiar with the internals but I've only seen things not reliably freed up between refreshes when a particular browser is getting too clever and trying to preserve things when you're not changing origins etc. in an effort to boost load performance.
In short, you could be tripping up a browser bug if you're not seeing memory freed as you expect but you'd want to use the various "about:memory" tools to verify that and at that point it would be on you to avoid such behavior and/or report the issue to the browser's dev team.
Otherwise, I think you're best served by addressing your own memory leaks within the page using the various tools available.
A good way to debug the resource usage of JS is to use the Firefox performance monitor within the inspection tool. Firefox Dev Edition has more in-depth tools
Press F12 when on the page and click on the little speedometer icon in the inspect window; this will open the performance monitor. Press the "Start Recording" button and Firefox will begin to benchmark all script timings, CSS activity, user input etc. on the page.
When you feel that it has been running for long enough, stop recording and you will be presented with all the data. At the top will be a chart displaying performance and you can click on any part and examine all the scripts running at that time.
A full tutorial for the performance tools can be found here
I've been working on a game in for HTML 5 using the canvas tag, and I've build up quite a code base to cover my requirements. I also want to make sure I'm covering up all my memory leaks.
I have doubts I'm doing it correctly because the feedback I'm getting from Chrome's task manager and profiling tools seem to suggest my cleanup is having no effect in the end.
Here's an image so you can see what I mean:
So as you can see, once I do my cleanup memory usage just freezes and doesn't drop. Is this a memory leak?
When I ran my webpage in the Profiler and checked the heap before and after cleanup it does appear to remove all the references to my objects (and they disappear) but my usage only drops by only a few kilobytes leaving about 1.3mb of arrays, strings, and other objects behind. Is it impossible to catch all this or is there something majorly wrong?
Thanks.
At the bottom of the profiler window there is an icon that looks like a trash can, it will force a GC pass.
Hit it and see if it clears up the rest of the memory.
It's possible Chrome/V8 just doesn't think the memory situation is bad enough to require garbage collection to run.
Try chrome://memory-redirect/ (or about:memory, both go to the same place). It'll show you the exact amount of memory being used by each tab/etc, plus the memory used by tags/etc in IE, Opera, Firefox, etc. if you have those open at the same time. The raw numbers should be a little more helpful than just the graph at profiling your memory use for potential leaks.
You can compare two heap snapshots and see the delta. You can also directly look at the memory snapshot: https://developers.google.com/chrome-developer-tools/docs/heap-profiling-comparison?hl=pt-PT
It seems that there is a lot of information on memory leaks in IE and how web developers can avoid them, but I can't find much on avoiding leaks in FF. I've found lots of random tips on how end users can tweak their preferences, or tips for extension developers, but little on what I can do as a web developer to make sure my pages don't leak. Am I missing something? It seems lazy to just blame it on the user and say "you've got too many extensions". Or are the major patterns the same as in IE -- circular references and all that?
Also, if anyone knows of any tools to troubleshoot leaks in FF, that would be great. I found this:
https://addons.mozilla.org/en-US/firefox/addon/2490/
But it's apparently just for chrome and extension development.
Outside of the design patterns to favour the only truely safe way is to test your pages thoroughly. To monitor the memory usage of the browser Task Manager is alright but Process Explorer provides more accurate results.
JavaScript is one cause of memory leaks but be careful with flash movies on pages too. Our content team added a movie from our design department that used a thrid party transition affect and this swallowed 10Mb every 20s or so. Just watching the movie loop through it was obvious in TaskManager to see the memory jump when the affect occured and the it never quite release it all back.
You can force to run a Garbage Collector in FireFox. The Garbadge Collector will destroy & release objects that are not used anymore. The only possibility of "Leaking memory" with a Garbage Collector is not a "leak" but a reference which makes no sense: remove all references to objects that you don't want to use.
Read more on this page:
http://adblockplus.org/blog/different-ways-to-force-garbage-collection
A bunch of what you read about how to avoid memory leaks in browsers is about how to avoid things that cause the browser to fail to reclaim memory that it should reclaim.
However, a more substantial problem in many cases is about Web pages holding on to objects that they don't need anymore. It's only the browser's job to reclaim things that are no longer "reachable" -- that is, things that the script / page can't get to anymore. If you're accumulating objects in an array and not removing them when you're done with them, memory usage will go up as the array gets bigger, and there's nothing the browser can do about that.
To phrase that another way: that's an issue of a memory leak in the Web page rather than in the browser. And the tool you want for that is a memory profiling tool to examine the objects that are reachable in your page, so you can tell whether there's stuff in there that you should no longer be holding on to. Writing such a tool for Firefox has been on my list of things to do for a while, but I haven't gotten around to it yet. I think there might be some ongoing work on writing one that integrates into Firebug.
I don't know if there is specific information for Firefox, but the generic tips still apply.
I suggest that you closely examine all loops and recursive functions. Re-use existing objects over creating new ones, and ensure that temporary objects and primitives exit scope so that they can be freed.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is the best way to profile javascript execution?
I have a few scripts that use jQuery, and I think I have a memory leak in one of them.
How one could profile and find what parts of the scripts that I have are using the most memory/CPU?
Regarding memory consumption
Memory leaks in JavaScript are usually ignored except when they turn into browser memory leaks (that is, even after the user navigates away from the page, the memory continues allocated and there's no way to free it). The reason for this is that while your web application may have some memory leaks, users will go from one page into another so the leaks are minimized. However they may not restart the browser, so browser memory leaks may be serious. Some JavaScript code is known to cause memory leaks on certain browsers, being Internet Explorer probably the worst in this area. For it you may find Microsoft JavaScript Memory Leak Detector to be very useful.
Regarding times
IE, Chrome and Safari have built in profilers in the web development tools that ship with the browser. For Firefox you may use Firebug. Also useful may be, since you're using jQuery which means your profiling report will be filled with anonymous functions and alike, making it quite unreadable, John Resig's jQuery profiling plugin, which will give you a clearer output on the matter.
Use Firebug. To quote from http://getfirebug.com/js.html:
To use the profiler, just go to the Console tab and click the "Profile" button. Then use your app for a bit or reload the page and then click the "Profile" button again. You'll then see a detailed report that shows what functions were called and how much time each one took.
I would suggest taking a look at the profiler in Firebug, and the Drip plugin for IE to help look for memory leaks.
Also, just keep in mind that most javascript memory leaks come from circular references between DOM objects and javascript objects not being broken when the DOM object is unloaded. To prevent that, I would suggest avoiding creating references to javascript objects in DOM object properties (ie, avoid something like document.getElementById('foo').bar = myObject;). If you must create these circular references, be sure to break them yourself in a function that runs when the page unloads, or when removing the DOM objects prior to unload.
Google Chrome also has profile options
Another simple way to test a specific piece of code is to add a timer around it.
var testStart = new Date();
// code to be tested here
$('#jstest').html("selected function: "+ (new Date() - testStart) + " milliseconds");
Where jstest is a span element somewhere visible on your page.
Though chrome has profiling options inbuilt it does not give precise information about the object.So i prefer using leak-finder-for-javascript tool which helped me in my code.
https://code.google.com/p/leak-finder-for-javascript/
I hope this helps.
Firebug or Google's Page Speed for Firefox have profiling tools.
This post by John Resig (jQuery) may be helpful for detecting memory leaks in IE:
http://ejohn.org/blog/deep-tracing-of-internet-explorer/