Comment by cmadan | Hacker News Reader

Comment by cmadan | Hacker News Reader

Parent Full thread

We at ClinchPad, which also uses a card based layout similar to Trello, faced the same issues. For every 100 cards, it'd add another 1-2 seconds to the load time meaning when you got to about 700 cards it would be close to 10 seconds of load time.

Here's how I fixed it

1. I added pagination - Load only 300 cards, paginate to load more. We found that while some people had 300+ cards in their default view, most never actually utilised the view usually using a filter to bring down the no of cards to a more manageable level.

That still left about 3-6 seconds of page load time for 300 cards. Unacceptable. So these where the further steps I took to fix it.

2. The main culprit after some rudimentary profiling seemed to be the jQuery's .html('') tag. Apparently it does some cleanup which takes awhile on a huge DOM block with lots of attached events. Replaced it with by looping through each child node in the DOM block and removing them with removeChild. Achieved 8x speedup, loading time down to 1-2 seconds with 300 cards.

3. Second culprit was the jQuery UI's droppable and draggable initiations was taking awhile. Hacked around this by putting the jQuery UI's droppable and draggable initiations inside a setTimeout thats fired in 100ms. Of course, this doesn't affect the actual rendering time but the perceived rendering time is now <1sec because the pipeline loads instantly and it is usually 1-2 seconds before the user does an action on the UI.

All in all, just less than <20 lines of code changed but took me two full days to figure it out. At one point, I was looking through jQuery UI's droppable code and futility seeing how I could optimize it. :)

My tips:

Avoid JQuery and use JavaScript 5 native API, if it's reasonable target (no IE8 < 9).

Check out http://jsperf.com/popular and use fast (and sane) methods.

What does "no IE8 < 9" mean? No versions of IE less than 8, less than 9, or something else?

No version of IE8 that has a version number lower than IE9.

I am having difficulties understanding the explanation - how can IE8 have a number equal or higher than IE9?

Because IE7 8 9.

it was a typo, I meant IE older than version 9 (IE < 9)

btw. JQuery 2 dropped support for such older IE version too

> The main culprit after some rudimentary profiling seemed to be the jQuery's .html('') tag. Apparently it does some cleanup which takes awhile on a huge DOM block with lots of attached events. Replaced it with by looping through each child node in the DOM block and removing them with removeChild.

It's important to let jQuery clean up its event handlers, otherwise you'll end up with memory leaks.

This is important to remember but hopefully not relevant. If you have event handlers on each card instead of delegating them to the container, that's a performance problem all by itself.

Can you clarify what you mean here? If I were writing a Backbone app, you mean I should bind to data attributes or similar instead of creating a new view for each item in a list?

If you have a list of thousands of items, attaching event handlers to each of those items separately is relatively expensive, although it makes the view code nicer. If you are as serious about performance as these people, you would want to add delegated events on the parent level. There is a writeup about doing this in Backbone [1] although I can't vouch for it.

In fairness, getting really good dom performance out of Backbone is hard because of the lack of built-in delegated event support and the non-synchronized redraws. If you have big apps that need to be super-fast, either read up on dom performance practices and adopt some helper libraries along with Backbone, or try a framework that has its own draw cycle and delegated event support.

[1] http://lostechies.com/derickbailey/2011/10/11/backbone-js-ge...

> getting really good dom performance out of Backbone is hard because of the lack of built-in delegated event support

It actually is builtin: https://github.com/jashkenas/backbone/blob/1.1.0/backbone.js...

In fact it takes a bit of effort to not use event delegation when setting up your events dict.

Well, Backbone handles delegation for elements within the same view. But it doesn't handle the case where you have lots of instances of the same view class in a list and want each handler registered only once for the whole list. You can do this manually by checking out the event target and maintaining a mapping from dom nodes to views, which you ought to do if you have lists of hundreds or thousands of repeated subviews. But Ember and various Backbone plugins can do this for you automatically.

> it doesn't handle the case where you have lots of instances of the same view

Wait I'm getting confused. Didn't the title post and your linked article both say not to do this if performance is the goal? (See "Tuesday" in OP). Isn't that what we're talking about here? Sorry if I misunderstood.

Yeah, I think this is just a terminology problem. Let's just lay out the complete answer: if you have a list of 1000 things to render in the same way, you can make it faster in various ways:

1. Don't render all of them at once, use pagination or infinite scroll.

2. Don't attach dom events to each item individually, instead attaching one event listener to the list container and having a way to go from the event's target to the appropriate view to act on.

3. Don't even create a view object for each item, just render them with the same template and have a composite view that knows how to act on each item's model for the delegated events.

It's important to understand the relative performance benefits of these changes. #1 will make things faster in proportion to how much the page size is smaller the the full list size. #2 will reduce the number of DOM calls by a factor of the number of items in the list. #3 will reduce the number of JavaScript objects created. #2 gets you a 10x-100x bigger speedup than #3. JavaScript fast, DOM slow.

That article advocates instantiating a View per model object in direct opposition to the delegated approach. It acknowledges that there may be performance implications on large collections, just as the title post found. Are you sure that is the article you intended to reference?

The thing is, when you profile a typical backbone app, with a list of view.

Most of the time (IIRC 60-70% for ~20 events) is spent registering DOM event handlers. Instantiating the view itself is nothing in comparison.

So registering all the events on the container and delegating (in the POO meaning not DOM) give you a very good performance without scarifying too much your code complexity.

Yup, it's the DOM stuff and not the js initialization that is the bottleneck. This is why Ember and React can be faster: you still have the same number or more js objects, but the automatic event delegation and managed draw cycle minimize dom changes.

This was going to be my comment as well.. better to detach the elements, and put them into a queue to remove completely in a timer loop... this way cleanup happens out of band.

I worked on a rather large extjs app, and IE was particularly bad about cleaning up dom objects with events attached, leading to memory leaks so bad that IE <= 8 would need to be reloaded a couple times a day. Firefox at the time was much better, and chrome was really new (so was IE8 at the time).

jQuery is good about keeping track of events and properly cleaning up, but it is expensive... though it's easy enough to .find('> *') and detach them, pushing those items into a cleanup queue.

Cool product. Looks similar to Pipedrive[1]. Incidentally, they came before Trello.

[1]: https://www.pipedrive.com/

Thanks! :)

About events: a nice trick is to add event listeners to the window only and check the event.target.

This method is used in game dev a lot.

+1 where it makes sense.. however this doesn't work well with a modular application, and could lead to a lot of higher level handlers/listeners.

I think the more expensive cost is cleanup, or lack of proper cleanup leading to memory leaks... I'll usually detach nodes to cleanup, and put them into a queue that's run in a setTimeout loop... that way they don't slow down the UI.

For #2, attached events in the child nodes may still be bound. This may lead to more memory usage than needed. Of course, if you don't have any bound events in the children, it'll work. Maybe a work around for any child events would be to delegate them on the parent container and just remove that one when you clear everything.

Reply on news.ycombinator.com