- Figure out what can be done to improve MD Settings performance.
- Verify whether the current Polymer usage in MD Settings is reasonable, not
only in terms of performance but also in code layout/structuring.
Need a way to track performance.
- How fast/slow is current MD Settings?
- Comparison with old settings.
- Be able to reason about how much time every change saves or costs.
Initial examination of the timeline during startup shows lot of long running
scripts, GC pauses, resize events. Need to dig in further and see if those are
justified. Overall need roughly a 10x improvement to match old settings startup
Things we can do to improve:
- lazify the UI, Only construct what is being displayed. Constructing elements
and just adding "display: none" is not as cheap as delaying constrcution.
- vulcanize, flatten as much as possible to reduce resource fetching overhead.
- use latest Polymer (there have been improvements).
- remove Polymer elements that have no view component (like cr-events).
Context: Polymer elements are not as cheap as native DOM elements (like div).
Specifically for <cr-events> it seems that it simply wraps static methods
in a Polymer element, which then is constructed multiple times for no good
- Focus on optimizing (or make lighter) widely used elements like
<settings-checkbox>. Think about the cost of adding features to it that are
only used by a small minority of instances (for example the policy-managed
paper-icon indicator that is included with each checkbox).
- Don't use polymer elements when there is no good reason. For example
taking a <paper-button> and making it look like a normal link (<a>) is not
helping peformance. Why not use <a> directly.
Note: Some paper elements will get faster going forward since there is an ongoing
effort from the Polymer.
Feel free to add things I missed above