CODEWITHSUNDEEP
backbone.js
ZekeDroid
ZekeDroid

Reputation: 7209

Pitfalls of setting Backbone Collection.models versus using Collection.reset

I hit a performance obstacle when trying to instantiate a Collection by passing it directly the list of Models or by using Collection.reset. It takes about 6000ms to initialize it with 4800 Models with about 200 attributes each. This isn't that large so it's a bit surprising to start off, but going off of this, I tried to speed it up by setting Collection.models directly to the array of models, and setting Collection.length to the length.

The question, other than the initial sorting, what is the difference between these two methods and where are the resources being spent? I use reset to initialize the Collection so there is no need to remove event handlers on the Models or to clean anything up.

USE CASE:

Trying to display a table with infinite scrolling, where each row is a Model and the Collection is the collection of rows. Each row can have about 200 columns. This is a static table except for a single column which contains a checkbox. The Models aren't doing anything else.

Upvotes: 3

Views: 135

Answers (1)

rjz
rjz

Reputation: 16510

There's a bit more to collections than their models and length.

When assigning directly, we're bypassing any other behaviors (sorting, existence-checking, etc) defined by the collection. Both reset and the constructor (which ends up delegating to reset) use the collection's heavy-ish set method to ensure new models are added consistent with the collection's designed behavior.

Direct assignment may be ok if the models will always be reset (i.e., not added or removed individually), but certain collection features may exhibit unexpected behaviors if the models are not set.

Upvotes: 2

Related Questions