|Possible memory leaks in Internet Explorer 7/Backbone?||Marcus Efraimsson||10/10/11 9:01 AM|
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
|Re: Possible memory leaks in Internet Explorer 7/Backbone?||Marcus Efraimsson||10/10/11 1:10 PM|
|Re: Possible memory leaks in Internet Explorer 7/Backbone?||Peter Rust||10/11/11 10:29 AM|
That's a very clear, helpful article by Derick Bailey (http://
transitions-in-backbone-apps/), I'm going to ask all the devs on my
team to read it. Not understanding this issue doesn't just lead to
memory leaks; it leads to bugs. We had a number of bugs when we
started using Backbone due to "zombie" views handling events after
they were supposed to be dead.
I'm sure most backbone developers have run into this. So far we've
been pragmatic and taken an approach similar to Derick's (manually
adding a "this.model.unbind(...)" to pair every
"this.model.bind(...)") but we've been planning to switch to a more
automatic approach, like Johnny Oshika's (http://stackoverflow.com/
7607853#7607853). It would be great if Oshika's approach or something
like it was built into Backbone.View, as this is an issue that every
Backbone developer needs to be aware of and address. As an alternative
to putting it in Backbone.View, it could be put in a new class,
something like Backbone.EventSubscriber, as it is not a unique need of
views, as Derick mentions -- and could be made available to views via
inheritance or composition.
Backbone Event subscriptions aren't the only thing that need to be
cleaned up when a view is destroyed -- you also need to consider any
pending asynchronous calls via setTimeout(), setInterval(), AJAX, and
any pending local asynchronous data access calls (like indexedDB or
the now-deprecated web SQL API).
A separate problem is tracking nested views (and in our case, also
nested controls) and remembering to call the clean up method (Derick
Bailey's view.close() / Johnny Oshika's view.dispose() / we put the
functionality in view.remove()) on each of them. The number of views
and nested views in our app continues to grow and it's challenging to
verify that each and every view -- and nested view -- is removed
properly. A few weeks go by and another bug crops up because someone
forgot to call the clean up method somewhere. This is a topic for a
separate thread, but we've considered either managing it from the DOM
perspective (DOMNodeRemoved event and/or overriding jQuery methods as
jQuery UI does to provide a remove event:
or managing it from the View perspective (maintaining collections of
nested views and nested controls).
-- Peter Rust
Developer, Cornerstone Systems
On Oct 10, 1:10 pm, Marcus Efraimsson <marcus.efraims...@gmail.com>
|Re: Possible memory leaks in Internet Explorer 7/Backbone?||Johnny Oshika||10/11/11 10:54 PM|
You make some excellent points. Thank you.
It's nice that Backbone is light and small, but it leaves out a lot of
important architectural designs. This requires each developer to have
to define them themselves. I too wish that Backbone had more "best
I've encountered (as I'm sure many others have too) the problems you
describe with nested views and managing their disposals. The solution
that I've adopted is to track all of the nested views in my base view
(where the base view is the view that all other views inherit from) so
that whenever "dispose" is called on a view, then all of the nested
children are disposed recursively. If anyone knows of a better
solution, I'd be interested to hear about it.
> jQuery UI does to provide a remove event:http://stackoverflow.com/questions/2200494/jquery-trigger-event-when-...)
|Re: Possible memory leaks in Internet Explorer 7/Backbone?||Peter Rust||10/13/11 8:10 AM|
> in my base view so that whenever "dispose" is called on a view, then
> all of the nested children are disposed recursively.Yes, we're doing the same thing. The only problem is remembering to
add every newly-created nested views to the list in the base class. I
was talking with my boss about this yesterday & I think a pragmatic
approach will be to add a createView(view_name, args) helper method in
the base class that both creates a view and adds it to the base class
list. So long as we exclusively use this method to create nested
views, they will all be cleaned up properly.
|Re: Possible memory leaks in Internet Explorer 7/Backbone?||Johnny Oshika||10/13/11 9:50 PM|
Sounds like a good approach, Peter.