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.
Related
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've been playing around with Backbone to see if this framework is a good choice to build on from now on and forward in our application. One requirement is that we must support Internet Explorer 7+ and another is to show at least 200 items per page.
To test the framework I've built a pretty simple list and it works flawlessy in all major browsers except Internet Explorer 7. It seems like there are some memory leaks since each time I reset the data the total rendering time are increased.
I've setup some test scenarios:
With events declared: http://jsfiddle.net/mefraimsson/a2YMF/
Without events declared: http://jsfiddle.net/mefraimsson/u6byQ/
One idea I had was that the events declared never was cleaned up when elements was removed and added to the DOM. When I run the test scenario "without events declared" clicking Reload data frequently the rendering time are pretty stable, but running "With events declared" the rendering time are increased rapidly and the amount of memory used for IE7 is increased. That's why I think that there is some memory leak somewhere.
Are there anyone who have experience with rendering of such large amount of data with Backbone?
Are there anyone who have experienced memory leak problems working with Backbone?
Do you recommend another approach when working with such large amount of data with Backbone? Instead of a large amount of sub-views use one view and iterate over data in template could be a possible solution, but then it feels like you don't get the most out of Backbone?
What is your opinion, do you think it is related to the declaration of events or is it the implemenation of Backbone that's leaking memory?
Thanks in advance
Memory leaks are a common problem in Javascript apps in general. I think there are some frameworks which try to handle this for you, but backbone doesn't. The browser you're using does make some difference in how those leaks are noticed and the problems they cause, but they still exist in other browsers, too. It's generally not the browser that's at fault, but the way event binding is handled in Javascript through the use of callback functions.
I wrote an article discussing this with a suggestion for a way to handle it, specifically with views: http://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/
Be sure to read the comments, too. There are some other great suggestions for handling memory leaks in there.
When I use jQuery UIs I find that the events always take up a lot of memory. When I change one web browser tab, then the memory decreases.
For Example, a very simple example:
<script src="jQuery & UIs"></script>
$("#item").draggable();
Then I drag the item, the memory costs very mush. When I switch between pages then the memory decreases to the original level.
This of course could not be called the memory leak but it takes a lot of memory too.If customer does not change the browser tab the browser will also not be so fluent because of the high memory token.
Maybe this is caused by the jQuery UI structure or the efficiency is not so much high?
When I see other javascript libs I find they will not take so much memory. So I wonder if there is any way to improve this or other ways to decrease the memory token?
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.
Is there a tool/plugin/function for Firefox that'll dump out a memory usage of Javascript objects that you create in a page/script? I know about Firebug's profiler but I'd like something more than just times. Something akin to what Yourkit has for Java profiling of memory usage.
Reason is that a co-worker is using id's for "keys" in an array and is creating 1000's of empty slots when he does this. He's of the opinion that this is harmless whereas my opinion differs. I'd like to offer some proof to prove whether I'm right or not.
I haven't tried the Sofware verify tools, but Mozilla has tools that track overall memory consumed by firefox for the purpose of stemming leaks:
http://www.mozilla.org/performance/tools.html
and:
https://wiki.mozilla.org/Performance:Leak_Tools
There's also this guy saying to avoid large arrays in the context of closures, towards article bottom
http://ajax.sys-con.com/node/352585
I think JavaScript Memory Validator from Software Verification Limited can help you, it has allocations view, objects view, generations view, etc. It's not free but you can use the evaluation version to check your coworker's code. They also have a Performance and Coverage Validators...
See the source. Sparse arrays don't take up lots of memory, but if your colleague doesn't need any Array functionality, he should be using plain Objects anyway.
Try also about:memory which shows how much memory each window occupies and how much of it is dedicated to JS objects. It gives high level summary without per object usage, but it is a good starting point for investigating memory requirements of a site.
You can use Mozilla’s Developer Tools. In order to use advanced developer tools of Firefox you need to create a debug build instead of a release build. For more on building process, see the page. Also, more information about using Mozilla’s Developer Tools you can find in this paper.