Performance Optimizations

[evancohen]

It's been a while since I've looked at the mirror's performance. The start-up time is getting pretty bad, and I feel like it no longer feels smooth. I'm going to spend some time investigating the following:

• Atrocious CPU hogging from FitBit. It's by far the most CPU intensive thing that happens on the mirror and it's really slowing things down (see chart below).

175dc98 I made a few optimizations to the way that FitBit loads in its dependencies, for most users this should decrease start time by 25% and use way less memory.

• Minimize/Avoid Watchers. Angular uses dirty checking to keep track of all the changes in app, we've been pretty careless about creating these and I think it's creating a performance impact.
  • Stay away from {{}} type bindings.
  • Leverage $watchCollection for calendar and other lists.
  • Use ng-if instead of ng-show.

b12bfb6 used ng-if for a 7% performance increase on boot.
ac225cf eliminated brace style binding for ng-bind. This improves performance over time and saves ~20% every scope.$digest

• Greedy Services. Today, most services initialize themselves when the mirror loads - for some service (ie: weather, calendar) that is necessary, but for others that load on command we should defer (ex: Dilbert, XKCD).
• Use Angular Components. The code has gotten a bit tangled and we are loading in a bunch of things that really should be brought in "on demand".
• Memory leaks. Some people (like @7h30n3 below) have reported that the mirror crashes or becomes unresponsive after running for long periods of time. This could be due to a memory leak, I'll need to start running tests for this on a more regular basis.
• Don't Use Angular 1.x. Some options:
  • Move to Angular 2. Along with a bunch of performance optimizations, Angular 2 also users TypeScript, which would be hugely beneficial to our build system endeavors and improving the quality of PRs.
  • Use React. A port to React.JS would be a lot of work, but would give us some great benefits (It's nice to the DOM and is known for it's performance).

Notes:
I don't want to focus too much on boot time, in most cases the mirror boots and then is left running for a long period of time. The bulk of the optimizations that I would like to make here are for lower CPU usage over time and quick responses to commands.

Aforementioned Chart:
Generated on a beefy Windows machine using Chromium Profiler in the Dev tools.

[kurtdb]

I created the performance-improvements branch to see what we can do to make it stable.

A few pieces of advice I got from a colleague:

• use one-time binding in stead of {{}} if the value will not change.
• use ng-if in stead of ng-show/ng-hide, since the later ones will still render the output in your DOM.
• create smaller controllers for the specific functionality. Combined with the ng-if, we could circumvent certain services from loading at all.
• use myApp.config(['$compileProvider', function ($compileProvider) { $compileProvider.debugInfoEnabled(false); }]); to circumvent angular from setting debug info in your html.

Might also be a good idea to look into directives to keep the HTML clean. It is usually only used for reusable components, but in a one-page layout project like this it might also have its use.

[7h30n3]

Performance improvements would be very appreciated.

After I finally finished the frame for my smart-mirror I made a long-term test (over night). As I wanted to talk to the mirror in the next morning it was totally unresponsive. For example it detects the hotword, but before the white shine at the button appears the mirror already stops listening.

Also I have a constant cpu load of 40% (Pi2). I think thats because of the hotword detection.

[evancohen]

@7h30n3 believe it or not, the hotword detection/keyword spotting is just about the most efficient thing in the mirror today 😉, for the Pi Zero it uses < 10%. I don't think 40% CPU load on the Pi 2 is all that bad, to be honest. We might be able to optimize some things here, but the optimizations that we can make for the mirror likely won't decrease overall CPU consumption by much, mostly because x just isn't that optimizable for what we are doing.

Regarding the mirror being unresponsive: uh oh! that's exactly what we don't want happening. This could be because of a memory leak (I've added a task here to investigate it).