Mastering Web Application

Chapter 11

Always remove all the calls to the consol.log in your production

code and use tools like jshint to assist you in this task. Never use

logging statements in the middle of the profiling/performance tuning

session as those statements will falsify the observed results.

Filters code is another place where we might unknowingly introduce expensive
computations. Consider the following example:

{{myModel | myComplexFilter}}

A filter is nothing more than a function invoked using special syntax as part of
AngularJS expression. Since it is part of a watch-expression, as such it will get
executed at least once (twice most of the time) per each $digest loop. If logic
executed in a filter is expensive it will slow down the entire $digest loop. Filters
are particularly tricky since they can declare dependencies on services and invoke
potentially expensive methods on services.

Each filter in the AngularJS expression is executed at least once

(usually twice) for a given $digest loop. Monitor logic executed as

part of the filtering method to make sure that it doesn't slow down

your application.

Avoid DOM access in the watch-expression

There are times where you might be tempted to read DOM properties as part of the
watchExpression. There are two problems with this approach.

Firstly, DOM properties access can be slow, very slow. The issue is that DOM
properties are calculated live, synchronously, when a property is read. It is enough
to watch a property whose computation is expensive to significantly slow down the
entire $digest loop. For example, reading a property linked to elements position or
dimensions will force a browser to recalculate the element's size and positioning, and
this is an order of magnitude slower as compared to observing JavaScript properties.