4 ms·

Great job! I'm not entirely sold that you needed to go that far outside vanilla AngularJS though. If you follow #3 strictly and throw out #1, I don't think yo

Great job! I'm not entirely sold that you needed to go that far outside vanilla AngularJS though. If you follow #3 strictly and throw out #1, I don't think you need #2 and #4, which are the ones that break the spirit of the general style of development in AngularJS. Creating elements dynamically is not a high-latency operation in modern browsers. This means in most cases, elements with a lot of watchers inside should not be hidden, but destroyed and recreated on demand, along with the scopes where the watchers are registered. As you found out, watchers are by far the most expensive part of AngularJS, because they run every digest cycle, and the solution isn't to manually manage them, but rather use the natuarl AngularJS mechanisms (ng-if, transclusion, ng-switch, and if you're on an older version of AngularJS without ng-if, ui-if) to not even render those parts until needed. ng-show in general should not be used to show and hide elements with lots of watchers inside them. What version of AngularJS are you on? The latest should have "track by" for ng-repeat, which should largely alleviate your concerns about ng-repeat rebuilding the whole DOM when you insert new elements.

sczerwin 13y ago
When we were doing the profiling while developing the optimizations, we were surprised to find that the Javascript thread was spending something like 50% of its time in the method to remove a DOM element. Now, maybe that's because Angular is not removing DOM elements as efficiently as it could, but it was a bottleneck. You are right though that optimization #3 is a big hammer that helps reduce the need for the other optimizations, but in the end, we found using both gives us the best result. And the other optimizations which much in terms of code. We are using version 1.1.15 and already had AngularJS re-using the pre-existing DOM elements if it could. When we tested it (without optimization #3 turned on), we found that it still had too much lag so felt it was better to use the DOM caching optimization.
- candybar 13y ago
  Very interesting, thanks for the explanation!

sczerwin 13y ago

When we were doing the profiling while developing the optimizations, we were surprised to find that the Javascript thread was spending something like 50% of its time in the method to remove a DOM element. Now, maybe that's because Angular is not removing DOM elements as efficiently as it could, but it was a bottleneck. You are right though that optimization #3 is a big hammer that helps reduce the need for the other optimizations, but in the end, we found using both gives us the best result. And the other optimizations which much in terms of code. We are using version 1.1.15 and already had AngularJS re-using the pre-existing DOM elements if it could. When we tested it (without optimization #3 turned on), we found that it still had too much lag so felt it was better to use the DOM caching optimization.

candybar 13y ago
Very interesting, thanks for the explanation!