geeeeeeeeek
commented
8 years ago @rev087 Any progress on that? Cuz it just stuck there when I was inspecting wx.qq.com, an extremely large Angular project. The page was not responding at all.
Open rev087 opened 9 years ago
geeeeeeeeek
commented
8 years ago @rev087 Any progress on that? Cuz it just stuck there when I was inspecting wx.qq.com, an extremely large Angular project. The page was not responding at all.
ng-inspector currently runs very poorly on large apps, and this is mostly due to its naive approach to introspecting and detecting changes in the inspected Angular application.
Some profiling might be necessary to pinpoint the largest bottlenecks but it's safe to assume the biggest issue stem from the use of watchers, which the extension adds to every scope in the page.
Watchers are computationally expensive, and Angular best practices dictate that they should be used sparingly in an application. Due to the nature of a tool such as ng-inspector, this is not so simple.
One of the early ideas was to add and remove watchers based on wether the scope is collapsed or expanded in the UI. This approach has it's own issues, but an usability decision (based on user requests) was to open the ng-inspector panel with all scopes expanded, and objects/arrays collapsed. This undermines the benefits of toggling watchers based on the expanded/collapsed UI state.
Other ideas involve using watchers only on scopes that are currently visible in the extension's pane scroll viewport, along with their ancestors, but this approach introduces many complications - and in the end, depending on the structure of the scope tree might provide limited performance gains.
This is a complex issue, but nonetheless fundamental to the usefulness and usability of the extension, so ideas are very much appreciated!