search envelope-o feed check
Home Unanswered Active Tags New Question
user comment-o

Angular 7 - change detection triggered way too much

Asked by kuko
1 year ago.

I've checked how often daypilot scheduler triggers angulars change detection. Results made me worried.

Change detection is executed ~3000 times per minute even when component is "idle"

Below two examples, both with not much data nor configuration. Second video is clean angular7 demo example taken from daypilot documentation:

Example within my app:

Example within daypilot angular demo app:

1) Are you guys aware of this? This does not look healthy to me.
2) Can you ensure that this will not cause performance issues when a lot of data will be bound to scheduler?

Comment posted by kuko
1 year ago. seemeed like this could be the reason, but my config didnt overwrite default value (which is supposed to be `false`) and also after changing `autoRefreshInterval` to higher values, there is no impact on angular lifecycle method frequency.

Answer posted by Dan Letecky [DayPilot]
1 year ago.

There are two factors to take into account:

1. Frequency of change detection cycle calls
Angular fires the change detection cycle for pretty much any action, including callback functions that are called asynchronously (mousemove event handlers, setTimeout, setInterval callbacks, etc.). Even if the event handler is empty.

Any component that is not trivial will fire a stream of change detection cycles. So it's better to accept it and try to minimize code that is fired in ngDoCheck, ngAfterViewChecked. See also #2.

Most of the cycles are generated by the automatic width change detection code - which you can turn off using watchWidthChanges property (see

It also fires the cycle on every mouse move but that is unavoidable.

2. Change detection speed
The Scheduler supports automatic input change detection ("config" and "events" attributes). The changes are detected in ngDoCheck using full object comparison. That is convenient but expensive.

One way to solve this is to require an immutable object and use a simple object identity comparison. That is fast but very inconvenient.

The Scheduler provides direct API for loading events and updating the configuration which is very efficient and it doesn't depend on the check cycle. So instead of forcing immutable objects as "events" and "config" values there are two options:

  • use "events" and "config" for convenience when the data set is small
  • switch to the direct API when you display large data sets (at least for event loading)

See also:

Comment posted by kuko
1 year ago.

Setting `watchWidthChanges` to `false` stopped the madness indeed.

This question is more than 3 months old and has been closed. Please create a new question if you have anything to add.