Dbux is an Integrated Debugging Environment (IDbE) and Omniscient Debugger that makes JavaScript application's run-time behavior come alive, visible and interactive.
[x] 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
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.
Data Size
Observations
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.
socket.io
dbux-runtime
->dbux-code
transfer speedRuntimeDataProvider.addData
GraphRoot.handleRefresh
(will be part of the time spent duringaddData
)instrumentation
,runtime
,encoding
,runtimeWaiting
(currently includes a big part ofpostProcessing
),totalRuntime
,noDbuxRuntime