1

Is it just me or does ng-repeat DOM inserts not batch. As we all know DOM manipulation is slow and operations should be batched for performance. When using ng-repeat on a collection it should create the DOM elements in memory and then insert them all at once instead of inserting them one at a time.

Is there any advice on how to get this behavior?

Harry
  • 52,711
  • 71
  • 177
  • 261
  • 1
    Why do you think they would do it this way (one at a time)? From what I understand the Angular team worked in part with the Chrome team to optimize things, this seems like it would have been done already if it really works best? Do you have a test case? – shaunhusain Jul 09 '13 at 20:16
  • @shaunhusain I'm not completely sure, it's just what I observed. I see no documentation at all anywhere for batching behavior and I searched a decently long time. I don't think angularjs batches. – Harry Jul 09 '13 at 20:20
  • @shaunhusain unless you're asking for proof on batching being faster? Just look it up on google. – Harry Jul 09 '13 at 20:23
  • (not asking about batching being faster, meant that it didn't take advantage) So I actually started digging into the code-base myself and I think you're probably right, but I'm not sure how to avoid it: http://code.angularjs.org/1.1.5/angular.js search for ngRepeatDirective and you'll find the code. – shaunhusain Jul 09 '13 at 20:24
  • @shaunhusain yep, I also asked on angularjs irc before coming here. https://github.com/angular/angular.js/blob/master/src/ng/directive/ngRepeat.js – Harry Jul 09 '13 at 20:26
  • I'm pretty sure the angular guys have their reason. They work directly with the chrome team .Do you ? Did you patch their code and did it improve any performance ? Nope. So you cant state something unless you can prove your way of doing stuffs makes things faster without breaking the lib. Or it is just speculations. – mpm Jul 09 '13 at 22:19

1 Answers1

5

There is a very good answer about angular's databinding, from one of its creators.

See the comment below, where he explains why angular's dirty-checking approach is better than change listeners:

Change coalescence. Suppose you have an array of items. Say you want to add items into an array, as you are looping to add, each time you add you are firing events on change, which is rendering the UI. This is very bad for performance. What you want is to update the UI only once, at the end. The change events are too fine grained.

In other words, thanks to this dirty-checking approach, angular is already updating the UI only once, with all DOM changes.

Community
  • 1
  • 1
Felipe Castro
  • 1,623
  • 11
  • 10
  • 4
    It's not quite true to say that angular is already updating the DOM in a batch. It isn't; it's just that any DOM operations should run within a $watch, which in turn is only triggered by the dirty-checking (and therefore all changes run within the same loop.) However, the DOM updates themselves are not batched (just the methods that cause the DOM updates to happen), and dirty-checking could do several runs, leading to the DOM being updated in multiple separate iterations. This is still much better than updating the DOM ad-hoc when event handlers are fired, but it isn't batch-updating the DOM. – zcrar70 Dec 04 '13 at 13:44
  • You're right, even though the the UI is rendered only once, at the end (and that's what makes it faster) the DOM is still being updated on multiple iterations (not in a batch). I'll update the answer, thanks. – Felipe Castro Dec 04 '13 at 15:12