In my web application, when I load a js module, I will meet a performance problem. I can hardly do the drag-drop/click operation after the page run a few time (10+ mins).
So I think this must be caused by the js file, it may cause the memory leak, but I have not idea how to find the problem.
Any one can give me some suggestion?
I would give DynaTrace Ajax Edition a try.
Here is an article about one of the ways you can find memory leaks with Chrome's Developer Tools: https://developers.google.com/chrome-developer-tools/docs/heap-profiling.
Also, this article tells you about how memory leaks can take place in JavaScript, in general: http://www.javascriptkit.com/javatutors/closuresleak/index.shtml. The usual case is when there are circular references between JavaScript world and the DOM world. The JavaScript world does have a GC that knows how to clean up circular references, but the DOM world has an entirely different GC. Combining the two worlds in some ways (which look innocuous at first) can lead to memory leaks even in modern browsers.
If the memory fills up quickly it is often due to detached DOM trees. If these are canvas elements or images, they can take much more memory than they appear to in the profiler tool (because the image data is store somewhere else). This is just one example, of course - there are many ways in which you can fill up the memory quickly.
You want to use valgrind with the browser if you want to check for a memory leak.
Related
I have some JavaScript Functions with source code coming from larger JavaScript-files. They are created this way:
const function = Function("foo", "...<large JS source code>...");
When looking at the memory snapshots in Chrome, the source code of these functions is retained and create a large memory overhead. Is it possible to "release"/"drop" source code of functions in JavaScript?
EDIT
I am really keeping the function itself around and wonder whether it’s possible to tell the function to drop the source code from memory.
Internally Chrome uses the V8 JavaScript engine. This engine is a just-in-time JavaScript engine which means that it takes your JavaScript and it compiles it to machine code when it needs it. This is expensive; so V8 will cache the result of the compilation and (in most cases) will re-use the previously compiled code if you call the function again.
I believe function memory reclamation is handled by the V8 garbage collector. When a variable (or function) falls out of scope (there aren't any references left to it anywhere, including closures) then the garbage collector is free to reclaim that memory including the source code and cached machine code. The garbage collector runs periodically and will clean up any memory from anything still in scope. Generally speaking you shouldn't try to force garbage collection on your own, it should happen automatically, but with Chrome there is a way to force garbage collection using the developer tools.
If you remove any references to your function (remember this includes closures) and force garbage collection you should see the memory reclaimed. Use the Chrome Developer memory tools to see if your function has been reclaimed or not (look at "heap snapshots").
There's one other caveat to this: even if the memory is reclaimed it won't necessarily be released back to the operating system or even cleared. Many applications handling large amounts of small memory allocations will try to improve performance by trying to re-use previously allocated memory before asking the operating system for more. So if you're using a low-level memory inspector you may still see your code hanging around in memory even if it's been garbage collected and there aren't any useful references to it. Without diving pretty deep into the V8 internals it probably isn't possible to determine from a memory dump if your code is still in memory because of a memory leak or because Chrome allocated the memory and simply hasn't released it back to the operating system after internally cleaning up references to that memory.
I have a heap profile taken in Chrome Dev Tools, but I am not sure how to interpret the data. As a test, I created 10,000 WidgetBuilder objects, each with their own methods. I would like to profile out storing methods on instances versus the prototype and see how that affects memory and performance when my page loads.
Should I focus on Retained Size or Shallow Size?
Are the values listed in these columns in bytes?
What is considered a lot of memory?
You might want to start here:
https://developers.google.com/chrome-developer-tools/docs/heap-profiling
It goes into detail on how to understand what you're reading. As for what is considered a lot of memory that's a tricky question. If your website is targeted at mobile devices I would start there as a constraint. To come up with a good comparison I'd suggest running the profiler against sites that you use every day and observe the memory consumption there.
If you find you're using more memory than gmail you might want to rethink ;)
I also recommend checking out jspref:
http://jsperf.com/prototype-vs-instance-functions
There is a LOT of prior work done on that site in regards to performance testing. You might be able to save yourself some time.
I believe I have a memory leak in my Backbone.js app. I concluded this after I printed some of my Backbone.View objects to the console, and saw the cid #'s increasing to the hundreds after just a bit clicking around.
Is this increasing cid# a sure sign of a memory leak? Are there any Heap profiling tools I can see the objects that are created, like with Java language? What are the best practices with Backbone.js to ensure no leaks?
Thanks!
The best practice is to use listenTo instead of on and bind. And do not forget to stopListening when you remove an instance.
I would suggest to use Chrome profiler for leaks detection: https://developers.google.com/chrome-developer-tools/docs/javascript-memory-profiling.
Also you can try to use Chrome plugin for debugging Backbone apps:
https://github.com/Maluen/Backbone-Debugger for debugging Backbone apps.
The profiler is the only source to find out where the leaks are. But there's a much simpler way to see the bigger picture. Go to the timeline then memory in chrome dev tools. It's much easier to read the graph and will show you spikes in memory and DOM creation/destruction.
You shouldn't worry about cleaning leaks until you're app manages the memory as best as possible. Users WILL notice memory spikes because the app will chug; They WON'T notice 99.9% of the leaks.
You're time would be better spend learning how to manage memory in the browser. Backbone doesn't do a good job managing memory. To use memory better: Use object pooling on DOM nodes, update DOM elements when the model changes, keep as much javascript as possible out of the templates, only use the render function once, be careful when loading images. There's a lot of techniques. Here's an example of the techniques to make you're backbone app performant: https://github.com/puppybits/BackboneJS-PerfView.
This might be a bit vague.
I'm working on an Atari 2600 emulator in javascript (http://jsatari.com/demo/ and https://github.com/docmarionum1/jsAtari) and it just runs incredibly slow. In chrome around 15-20 FPS and in Firefox around 2-3 FPS (on my computer).
I've run through my code optimizing with Chrome's and Firebug's profilers and optimized whatever I could, but I'm FAR from what I need and I don't see much more room for improvement in my algorithms. (Or, at least not without significantly diverging from the original hardware implementation.)
And so far my biggest improvements haven't come from improving the algorithms, but from changing my data structures:
Switching my large arrays (thousands of elements) to Typed Arrays provided the biggest boost in performance. Firefox would freeze before the switch, and Chrome ran about 10x faster.
I replaced some smaller arrays with individual variables and switch statements, also providing a significant boost in performance.
So, it seems pretty clear that arrays are incredibly slow.
In general, performance just seems very finicky, with small changes in my code resulting in large changes to the performance (for better or worse.) Or there other oddities that could be affecting the performance?
For instance, are objects created with object literal notation represented differently by the engine? I've seen noticeable changes in performance when merely adding or removing variables from an object, even if they weren't being used. Should the number of variables affect that?
Are there any other new developments in javascript (like Typed Arrays) that could have a big affect on performance?
And, finally, is there any good way to track performance due to intangibles like these? The profilers don't seem to help because the entire script with change, not just certain parts.
I saw, that you create many closures (and directly execute them) for example in your UpdatePos method. The massive creation usage of closures as you do it may be a big performance problem.
I would recomment you to take a look at JavaScript optimization tools like Closure Compiler by Google http://closure-compiler.appspot.com/home I really can recomment using this with Advanced Optimization (but then you have to give him all you javascript code - otherwise or if you use eval you (might) get problems (because he renames not only local variables and deletes unused code))
I'm loading some fairly big data sets in to firefox (500 k or so) and drawing tables with them. Firefox is using up to 400 megs of memory. How can I tell if Firefox is leaking memory, or is just using a lot of memory just because it can?
Is there another browser which will use less memory if it doesn't need it? I get the feeling that firefox grabs a bunch of memory for itself and doesn't release it unless it has to. It may be apparent that my understanding of memory management in general is very superficial.
There is a setting you can set in firefox that forces it to free as much memory as it can on minimise:
On the website url toolbar type
about:config
A page full of words
will come up. right click anywhere
and choose New -> Boolean
For the
name input type
"config.trim_on_minimize" Select
True
Restart FireFox.
If it is leaking memory, then the mem usage (number of K) in your Windows task manager will continue to grow. If this number is fairly consistent, then Firefox is behaving normally. It is my opinion that Firefox requires far too much memory to behave normally.
How can I tell if Firefox is leaking memory, or is just using a lot of memory just because it can?
Open another page in a different tab. Then close your 'big' tab and see if the memory is freed.
Memory Leak - memory which is not released when it should be
If the memory Firefox is allocating to hold your data is released when you navigate away from your page, there is no memory leak. You can than argue if Firefox if using too much memory or not, but that is something beyond your scope.
You do have a leak on your hands if that memory is not released. In that case you should check if it is something you can handle in your JS code, or a firefox bug. If it's the latter, go ahead to the mozilla bugzilla, and open a ticket.
You can turn on Windows Performance Monitor and see if the firefox.exe process is growing memory over time to confirm if there is a memory leak.
I get the feeling that firefox grabs a bunch of memory for itself and doesn't release it unless it has to. It may be apparent that my understanding of memory management in general is very superficial.
well, at 1 point Firefox requires a lot of memory, say 400Mb.
maybe after that, it doesn't require so many memory, BUT
since your system do not need this memory, it does not reclaim it to Firefox, which keeps it.
If ever you launch other processes that need a lot of memory, then your OS will claim back memory to other processes that are running with a high priority.
To summarize my ideas : it's probably not a memory leak.
Is there another browser which will use less memory if it doesn't need it?
why don't you try them?