Skip to content

Usability Performance Discussion

Bruno Daniel edited this page Apr 18, 2015 · 16 revisions

This page will feature ideas for improvement regarding the introspection and change detection central to the extension functionality.

Related discussion: https://github.com/rev087/ng-inspector/issues/85

Performance Problem

This problem exists in both ng-inspector and Batarang.

ng-inspector

The main issue is that it adds too many watchers. It adds a single deep watch to every scope.

Batarang

The main issue is that it has to serialize big objects, creates large GC pauses.

Informative initial view

In ng-inspector, one thing users requested was that models were initially expanded. This made it easy to (at a quick glance) get a high-level view of the shape of the models on a scope.

However, this has a performance tradeoff. For Batarang, this means sending more info through different contexts. For ng-inspector, this means rendering more often.

Proposed solutions

Instrumentation should send over enough information to populate the screen in whatever state its in. We can do this by looking at the current viewport to see what things are being viewed.

We can look at scroll position and whether the part of the UI is expanded. Based on this, we can determine which parts of the scope are interesting. ng-hint has a method that's helpful: https://github.com/angular/angular-hint/blob/refactor-all-the-things/src/modules/scopes.js#L24-L48

Baselines

Deep nested arrays/objects, great performance

Very large number of scopes and models, abysmal performance

* I suspect this is in large portion due to the sheer number of DOM elements being handled in the extension UI rather than the actual instrumentation. @rev087

Large sites with decent performance

Medium-size sites with decent performance

Small sites with poor performance

Implementation in ng-inspector

The following are sites in the code that are interesting for implementing this strategy in ng-inspector.