Is it possible to track down(profiling) on what particularly memory were used.
For example this object eats this much memory, this one this much etc.
Thanks ;)
Using Chrome you are able to make a heap snapshot:
Open Developer Tools (F12)
Go to 'Profiles' tab
Click an 'eye' icon to make a snapshot
Browse created snapshot for desired object
In some browsers you can. For instance, in Google Chrome the location about:memory will give you detailed information about memory usage.
There are a number of tools available for this. One of which is JavaScript Memory Validator, it's a paid for product, but has a free trial.
Mozilla also has a list of useful js performance tools listed here.
Related
We need to implement undo functionality for a web editor and want to test how deep the undo history could reasonably go.
The undo data model is a JavaScript array containing 1+ jQuery objects, each of which could contain multiple Base64 images.
How can you measure memory usage of JavaScript objects? Is it possible to monitor memory usage from Chrome?
Chrome have a great tool for that. It's based on RAIL model and allows you to quickly detect leaks and even bloats. Just go to chrome's Task Manager (shift + esc) and enable Javascript memory. This tool saved my life, good luck!
There are built in tools in Chrome DevTools that allow you to inspect memory usage.
You can access them via the task manager (Shift+Esc or Main Menu > More tools > Task manager) then right click on Header and enable JavaScript Memory
You can find more info there:
https://developers.google.com/web/tools/chrome-devtools/#memory
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
I'm trying to do some performance/efficiency testing with Chrome Developer tools and their "Profile" tab...
I'm getting the following results When I load up the page, do a Heap Snapshot, refresh the page, Heap Snapshot, etc... repeatedly..
This question is 2 fold..
Is this normal? do I have a memory issue?
Can anyone point me to a resource to interpret the output of chrome's heap snapshot and cpu profiling?
This issue happens because you have chrome extensions that are retaining part of your DOM upon refresh for whatever reason.
When using the profile tools always go into incognito mode, no extensions are loaded here and you can be sure that the objects you see in the profile are only yours... well, mostly; you will also see chrome internal data structures wrapped in parentesis like (compiled code) or (system). Ignore those, you have no control over them.
Who would've said that incognito mode has other uses apart from... you know ;-)
It may or may not be normal. You'd have to analyze the difference between snapshots to tell.
Have you looked at the profiling docs?
Is there a way to check the resource usage with a javascript code?
Can i check RAM usage and cpu usage of the script?
Since there are various ways to do something, i might write the code using different methods, and save it in as 2 different files, and check which method is more optimized. Esp when i'm calling a function recursively.
This way, i'll get to learn which methods are better and what to use.
Anything like maybe an addon, or maybe a script to be added that does this. It would be much better if it shows function wise. I'm not sure if something like this exists.
On a note, with chrome inspector, i tried CPU profiling, but it seems to show me values according to time, and does not show the RAM/CPU usage.
There's no uniform cross-browser way to do this. You can get an overall sense of your javascript performance by using Chrome's Timeline tool. Switch between the Timelines and Memory tabs on the left and hit the record button at the bottom. I believe Safari has a similar tool.
Internet Explorer has the excellent DynaTrace tool, although I don't know it well enough to provide detailed instruction on how to use it.
Note that javascript interpreters vary wildly in implementation, so they may have very different performance characteristics. Rather than get caught up in the details of implementation (premature optimization is evil and all that), write your code with good coding practices in mind. That means that if you do have performance bottlenecks (which the profiling tools available will help you locate), you can refactor more readily.
I don't know any specific way to test the Ram and CPU stats of javascript. But I often user http://jsperf.com/ to see how two different functions perform.
Have you tried with Crome Tools > Task Manager in Chome Tools menu options? It shows the CPU and Memory Usage for each process running in the borwser (comprise chrome-extensions).
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/