The following scenarios are just a handful of the commonly encountered scenarios that degrade the application's performance and responsiveness.

<div ng-repeat="val in values | filter:slowFilter"></div>

$scope.$watch(giganticObject, function() { ... }, true);

$scope.$watchCollection(giganticArray, function(newVal, oldVal, scope) {
  var count = 0;
  // iterate through newVal array
  angular.forEach(newVal, function(oldVal) {
    // if the array snapshot index doesn't match,
    // this implies a change in model value
    if (newVal[count] !== oldVal[count]) {
      // logic for matched object delta
    }
    count++;
  });
});

<div ng-repeat="row in rows">
  <div ng-repeat="val in row">
    {{ val }}
  </div>
</div>

These are only a handful of scenarios that can cause problems for your application. There is a virtually unlimited number of possible configurations that can cause an unexpected slowdown in your application, but being vigilant and watching out for common performance anti-patterns will ameliorate much of the headache that comes along with debugging the slowness of an application.

The $scope.$watch(), $scope.$watchGroup(), and $scope.$watchCollection() methods are normally keyed with a stringified object path, which becomes the target of the change listener. However, if you wish to register a callback for any watch callback irrespective of the change listener target, you can decline to provide a change listener target, as follows:

// invoked once every time $scope.foo is modified
$scope.$watch('foo', function(newVal, oldVal, scope) {
  // newVal is the current value of $scope.foo
  // oldVal is the previous value of $scope.foo
  // scope === $scope
});

// invoked once every time $scope.bar is modified
$scope.$watch('bar', function(newVal, oldVal, scope) {
  // newVal is the current value of $scope.bar
  // oldVal is the previous value of $scope.bar
  // scope === $scope
});

// invoked once every $digest cycle
$scope.$watch(function(scope) {
     // scope === $scope
});

There's no trickery here; the universal watcher is a feature that is explicitly provided by AngularJS. Although it invokes $watch() on a scope object, the callback will be executed for every model's modification, independent of the scope upon which it is defined.

Although the watch callback will occur for model modifications anywhere, the lone scope parameter for the callback will always be the scope upon which the watcher was defined, not the scope in which the modification occurred.

The following function can be used to inspect all or part of the DOM for watchers. It accepts an optional DOM element as an argument.

var getWatchers = function (element) {
  // convert to a jqLite/jQuery element
  // angular.element is idempotent
  var el = angular.element(
      // defaults to the body element
      element || document.getElementsByTagName('body')
    )
    // extract the DOM element data
    , elData = el.data()
    // initalize returned watchers array
    , watchers = [];

  // AngularJS lists watches in 3 categories
  // each contains an independent watch list
  angular.forEach([
      // general inherited scope
      elData.$scope,
      // isolate scope attached to templated directive
      elData.$isolateScope,
      // isolate scope attached to templateless directive
      elData.$isolateScopeNoTemplate
    ],
    function (scope) {
      // each element may not have a scope class attached
      if (scope) {
        // attach the watch list
        watchers = watchers.concat(scope.$$watchers || []);
      }
    }
  );

  // recurse through DOM tree
  angular.forEach(el.children(), function (childEl) {
    watchers = watchers.concat(getWatchers(childEl));
  });

  return watchers;
};

With this, you are able to call the function with a DOM node and ascertain which watchers exist inside it, as follows:

// all watchers in the document
getWatchers(document);

// all watchers in the signup form with a selector
getWatchers(document.getElementById('signup-form'));

// all watchers in <div class="container"></div>
getWatchers($('div.container'));

It is possible to access a DOM element's $scope object (without injecting it) through the jQuery/jqLite element object's data() method. The $scope object has a $$watchers property that lists how many watchers are actively defined upon that $scope object.

The preceding function exhaustively recurses through the DOM tree and inspects each node in order to determine whether it has a scope attached to it. If it does, any watchers defined on that scope are read and entered into the master watch list.

This is only a single, general implementation of watcher inspection. Since watchers are localized to a single scope, it might behoove you to utilize components of this function in order to inspect single scope instances instead of the child DOM subtree.

Strategies to deploy watchers efficiently can be summed up as follows.

The reference watcher should be used when the object's properties are unimportant. It is the most efficient of the $watch types as it only demands top-level object comparison.

The watcher can be created as follows:

$scope.myObj = {
  myPrim: 'Go Bears!',
  myArr: [3,1,4,1,5,9]
};

// watch myObj by reference
$scope.$watch('myObj', function(newVal, oldVal, scope) {
  // callback logic
});

// watch only the myPrim property of myObj by reference
$scope.$watch('myObj.myPrim', function(newVal, oldVal, scope) {
  // callback logic
});

// watch only the second element of myObj.myArr by reference
$scope.$watch('myObj.myArr[1]', function(newVal, oldVal, scope) {
  // callback logic
});

The reference comparator will only invoke the watch callback upon object reassignment.

Suppose that a $scope object was initialized as follows:

$scope.myObj = {
  myPrim: 'Go Bears!'
};
$scope.myArr = [3,1,4,1,5,9];

// watch myObj by reference
$scope.$watch('myObj', function() {
  // callback logic
});
// watch myArr by reference
$scope.$watch('myArr', function() {
  // callback logic
});

Any assignment of the watched object to a different primitive or object will register as dirty. The following examples will cause a callback to execute:

$scope.myArr = [];
$scope.myObj = 1;
$scope.myObj = {};

Beneath the top-level reference watching, any changes that affect the inside of the object will not register as changes. This includes modification, creation, and deletion. The following will not cause the callback to execute:

// replace existing property
$scope.myObj.myPrim = 'Go Giants!';

// add new property
$scope.myObj.newProp = {};

// push onto array
$scope.myArr.push(2);

// modify element of array
$scope.myArr[0] = 6;

// delete property
delete myObj.myPrim;

The long and short of it is that reference watchers are the most efficient type of watchers, so when you are looking to set up a watcher, reach for this one first.

The equality comparator is used when the optional Boolean third argument is set to true. Other than that, these watchers are syntactically identical to reference comparator watchers, as shown here:

$scope.myObj = {
  myPrim: 'Go Bears!',
  myArr: [3,1,4,1,5,9]
};

// watch myObj by equality
$scope.$watch('myObj', function(newVal, oldVal, scope) {
  // callback logic
}, true);

The equality comparator will invoke the watch callback on every modification anywhere on or inside the watched object.

Suppose that a $scope object is initialized as follows:

$scope.myObj = {
  myPrim: 'Go Bears!'
};
$scope.myArr = [3,1,4,1,5,9];

// watch myObj by equality
$scope.$watch('myObj', function() {
  // callback logic
}, true);
// watch myArr by equality
$scope.$watch('myArr', function() {
  // callback logic
}, true);

All of the following examples will cause a callback to be executed:

$scope.myArr = [];
$scope.myObj = 1;
$scope.myObj = {};
$scope.myObj.myPrim = 'Go Giants!';
$scope.myObj.newProp = {};
$scope.myArr.push(2);
$scope.myArr[0] = 6;
delete myObj.myPrim;

Since a watcher must store the past version of the watched object to compare against it and perform the actual comparison, equality watchers utilize both the angular.copy() method to store the object and the angular.equals() method to test the equality. For large objects, it is not difficult to discern that these operations will introduce latency into the application. Equality comparator watchers should not be used unless absolutely necessary.

This watcher is best used with arrays or flat objects that undergo frequent top-level property modifications or reassignments. Currently, it does not provide the modified property(s) responsible for the callback, only the entire objects, so the callback is responsible for determining which properties or indices are incongruent. This can be done as follows:

$scope.myObj = {
  myPrimitive: 'Go Bears!',
  myArray: [3,1,4,1,5,9]
};

// watch myObj and all top-level properties by reference
$scope.$watchCollection('myObj', function(newVal, oldVal, scope) {
  // callback logic
});

// watch myObj.myArr and all its elements by reference
$scope.$watchCollection('myObj.myArr', function(newVal, oldVal, scope) {
  // callback logic
});

The $watchCollection utility will set up reference watchers on the model object and all its existing properties. This will invoke the watch callback upon object reassignment or upon top-level property reassignment.

Suppose that a $scope object is initialized as follows:

$scope.myObj = {
  myPrim: 'Go Bears!',
  innerObj: {
    innerProp: 'Go Bulls!'
  }
};
$scope.myArr = [3,1,4,1,5,9];

// watch myObj as a collection
$scope.$watchCollection('myObj', function() {
  // callback logic
});
// watch myArr as a collection
$scope.$watchCollection('myArr', function() {
  // callback logic
});

The following examples will cause a callback to be executed:

// object reassignment
$scope.myArr = [];
$scope.myObj = 1;
$scope.myObj = {};

// top-level property reassignment
$scope.myObj.myPrim = 'Go Giants!';

// array element reassignment
$scope.myArr[0] = 6;

// deletion of top level property
delete myObj.myPrim;

The following will not cause the callback to be executed:

// add new property
$scope.myObj.newProp = {};

// push new element onto array
$scope.myArr.push(2);

// modify, create, or delete nested property
$scope.myObj.innerObj.innerProp = 'Go Blackhawks!';
$scope.myObj.innerObj.otherProp = 'Go Sox!';
delete $scope.myObj.innerObj.innerProp;

The name $watchCollection is a bit deceptive (depending on how you think about enumerable collections in JavaScript) as it might not perform how you would expect—especially since it doesn't watch for elements that are being added to the collection. Since explicitly-defined properties and array indices are effectively identical at the object property level, $watchCollection is really more of a single-depth reference watcher.

When a watcher is initialized, it will return its deregistration function. You must store this deregistration function until it needs to be invoked. This can be done as follows:

$scope.myObj = {}

// watch myObj by reference
var deregister = $scope.$watch('myObj', function(newVal, oldVal, scope) {
  // callback logic
});

// prevent additional modifications from invoking the callback
deregister();

The $watch destruction will normally be needed when a change in application state causes a watch to no longer be useful while the scope that it is defined inside still exists. When a scope is destroyed—either manually or automatically—the watchers defined upon it will be flagged as eligible for garbage collection, and therefore, manual teardown is not required.

However, this is contingent upon the scope on which the watcher is destroyed. If your application has watchers defined on a parent scope or $rootScope, they will not be flagged for garbage collection and must be destroyed manually upon scope destruction (usually accomplished with $scope.$on('$destroy', function() {})), or else your application is subject to potential memory leaks in the form of orphaned watchers.

Curly braces are easily recognized as the AngularJS syntax for template data binding. The following is an example:

<div ng-show="{{myFunc()}}">
  {{ myObj }}
</div>

On a high level, even to a beginner level AngularJS developer, this is painfully obvious.

Interpolating the two preceding expressions into the view implicitly creates two watchers for each of these expressions. The corresponding watchers will be approximately equivalent to the following:

$scope.$watch('myFunc()', function() { ... }, true);
$scope.$watch('myObj', function() { ... }, true);

The AngularJS expression contained within {{ }} in the template will be the exact entry registered in the watch list. Any method or logic within that expression will necessarily be evaluated for its return value every time dirty checking is performed. An observant developer will note that any logic contained in myFunc() will be evaluated on every single digest cycle, which can degrade the performance extremely rapidly. Therefore, it will benefit your application greatly to have the value of the watch entry calculable as quickly as possible. An easy way to accomplish this is to not provide methods or logic as expressions at all, but to calculate the output of the method and store it in a model property, which can then be passed to the template.

Template watch entries have setup and teardown processes automatically taken care of for you. You must be careful though, as using {{ }} in your template will sneakily cause your watch count to balloon. AngularJS 1.3 introduces bind once capabilities, which allow you to interpolate model data into the view upon compilation, but not to bring along the overhead of data binding, if it will not be necessary.

Suppose that your application contains the following pseudo-setup. This is what we need for the next section:

(index.html)

<div ng-repeat="element in largeCollection">
  <span my-directive></span>
</div>

(app.js)

angular.module('myApp', [])
.directive('myDirective', function() {
  return {
    link: function(scope, el, attrs) {
      // general directive logic and initialization
      // instance-specific logic and initialization
    }
  };
});

A clever developer will note that since a directive's link function executes once for each instance of the directive in the repeater, the current implementation is wasting time performing the same actions for each instance.

Since the compile phase will only occur once for all directives inside an ng-repeat directive, it makes sense to perform all generalized logic and initialization within that phase, and share the results with the returned link function. This can be done as follows:

(app.js)

angular.module('myApp', [])
.directive('myDirective', function() {
  return {
    compile: function(el, attrs) {
      // general directive logic and initialization
      return function link(scope, el, attrs) {
        // instance-specific logic and initialization
        // link function closure can access compile vars
      };
    }
  };
});

The ng-repeat directive will implicitly reuse the same compile function for all the directive instances it creates. Therefore, it's a no-brainer that any redundant processing done inside link functions should be moved to the compile function as far as possible.

This is by no means a fix all for the sluggishness of ng-repeat, as high latency can stem from a large number of common problems when iterating through huge amounts of bound data. However, using the compile phase effectively is an often overlooked strategy that has the potential to yield huge performance gains from a relatively simple refactoring.

Furthermore, even though this condenses logic into a single compile phase per ng-repeat, the compile logic will still get executed once for every instance of the directive in the template. If you truly want the logic to only get executed once for the entire application, use the fact that service types are singletons to your advantage, and migrate the logic inside one of them.

When track by $index is used as an addendum to the repeat expression, AngularJS will reuse any existing DOM nodes instead of re-rendering them.

The original, suboptimal version is as follows:

<div ng-repeat="element in largeCollection">
  <!-- element repeater content -->
</div>

The optimized version is as follows:

<div ng-repeat="element in largeCollection track by $index">
  <!-- element repeater content -->
</div>

By default, ng-repeat associates each collection element by reference to a DOM node. Using the track by expression allows you to customize what that association is referencing instead of the collection element itself. If the element is an object with a unique ID, that is suitable. Otherwise, each repeated element is provided with $index on its scope, which can be used to uniquely identify that element to the repeater. By doing this, the repeater will not destroy the DOM node unless the index changes.

The following is the naïve method of an exhaustive equality comparator watch:

$scope.$watch('bigObjectArray', function() {
  // watch callback
}, true);

Instead of watching the entire object, it is possible to call map() on a collection of large objects in order to extract only the components of the objects that actually need to be watched. This can be done as follows:

$scope.$watch(
  // function that returns object to be watched
  function($scope) {
    // map the array to distill the relevant properties
    // this return value is what will be compared against
    return $scope.bigObjectArray.map(function(bigObject) {
      // return only the property we want
      return bigObject.relevantProperty;
    });
  },
  function(newVal, oldVal, scope) {
    // watch callback
  },
  // equality comparator
  true
);

The $watch expression can be passed anything that it can compare to a past value; it does not have to be an AngularJS string expression. The outer function is evaluated for its return value, which is used as the value to compare against. For each cycle, the dirty checking mechanism will map the array, test it against the old value, and record the new value.

If the time it takes to copy and compare the entire object array is greater than the time it takes to use map() on the array and compare the subsets, then using the watcher in this way will yield a performance boost.