Measure + improve performance

[Domiii]

Data Size

Observations

• A trace is about 200-300 bytes (JSON.stringify). Meaning 800 traces generate 200+kb.
  • dataNode is a little bit smaller.

Performance Analysis Basics

Need to measure each of the following on a variety of different projects.

NOTE: Always measure performance in Production mode.

• webpack build performance with + without Dbux
  • maybe we can use https://www.npmjs.com/package/speed-measure-webpack-plugin ?
  • we already added babel caching
• execution speed with + without Dbux
• file size with + without Dbux
• socket.io dbux-runtime -> dbux-code transfer speed
  • The main bottleneck here is encoding: fix notepack's encoding problems #570
• time spent visualizing the different Dbux components
  • RuntimeDataProvider.addData
  • GraphRoot.handleRefresh (will be part of the time spent during addData)
  • NOTE: while we don't have generalized performance counters for this yet, it is a lot less of a bottleneck, since we implemented lazy-load of graph node rendering.
• add performance profiling
  • instrumentation, runtime, encoding, runtimeWaiting (currently includes a big part of postProcessing), totalRuntime, noDbuxRuntime

[Domiii]

• Call graph rendering performance has mostly been solved with: Call Graph: Load/render roots (and each root's subtree) separately #458 and Feature: Render AsyncGraph #452
• Runtime performance needs the real work now. For that, we want to add more fine-grained control of what is to be recorded, and trim some of the fat that way.
  • NOTE: we are already batching data sent from Runtime client.