Angular - Nested $scope will produce nested $watchers?

Question

I'm encountering performance issues, I think due to lots of watchers in the page (more than 4000!!). The scenario is a (small, about 5) list of items in ng-repeat once, each one contains another ng-repeat for every day of week (so 7), and in each day container there are 1 or 2 input field. Each day's element has its own scope and controller and some watch at parent's properties, in order to update parent state at child changes. So a bit complex scenario...imagine an agenda view where each day as some input fields or buttons which update same property in the main scope, like "10 days selected/filled/clicked".

I started with about 5000 watchers, now reduced to about 4000 removing some filters and switching to translate-once directive insted of translate (angular-translate).

So the main question is:

How to further reduce the number of watchers?

Is every child scope inheriting the parent watchers, resulting in 7x for each watcher? If I remove child's controllers, leaving the job to the the parent (passing in the function the child item), will I decrease the number of watchers? Could this be a solution? Any help is appreciate.

Answer 1

In our experience that number of watchers cause no speed problems. The performance problems we have encountered in the last 8 months of development on a single big application were caused by slow third part's components.

For example, we have a page with two drag and drop trees with 14.600 watchers (because of high number of items in both trees). We experienced performance problems because of the component used, angular-ui-tree, and we reduced them opening the page with most of the tree collapsed.

We cannot change that component because it is the only one which features drag and drop between trees, but in another page where we had drag & drop between simple lists we have tried those two components: angular-dragdrop and angular-drag-and-drop-lists. The first had a lot of performance problems (with about 500 items) while the second run really really fast. In his documentation on github, section "Why another drag & drop library?" you can read why it is so fast and why the other is so slow.

So, I can speculate that third part's components bring you the real performance problems, and not the watchers.

In any case, we often write our watchers with a check like the one below to not run the code unless needed.

$scope.$watch('variableToWatch', function(newValue, oldValue) {
    if (newValue === oldValue) {
        return;
    }

    ... watcher code ...
}

Another way to reduce watchers from html is using one-time-binding. Example:

<div ng-if="::vm.user.loggedIn"></div>

Answer 2

Related to performance... - One pattern i came up with is to use a private object and assign the prototype of a function for easy access. then in any function ,controllers, directives...ect you can access the prototype of other function,controllers,directives easily. instead of using watchers you can use this pattern like a event loop. instead of angular running 300+ watchers every digest cycles. using this pattern only what triggers the function call matters.

An example of this pattern

var private = {} //accesable to entire app


var app = angular.module('some-app',[])
.controller('someCtrl',['$scope',someCtrl])
.directive('someDirective',someDirective);

function someCtrl($scope){
private.someCtrl = someCtrl.prototype



someCtrl.prototype.update = function(someDate){
//do something....
//access to someCtrl arguments  
  
  $scope.something = someDate
}


}

function someDirective(){

  var someCtrlProto = private.someCtrl;
return{
  link:function(scope ,elm ,attr){
  
    elm[0].addEventListener('click',fucntion(){
           someCtrlProto.update(someData) 
    
      });
      //or
    
    elm[0].addEventListener('click',someCtrlProto.update) //to trigger someCtrl.update from here
    }
  }
}