Skip to main content

Performance

There are many performance considerations in tracing and recording all activity of a program.

Performance Considerations

Main considerations include:

  • Instrumentation can be slow.
    • @dbux/cli uses a custom implementation of [`@babel/register`](https://babeljs.io/docs/en/babel-register). * That implementation provides improved caching. Make sure to enable `caching` when using @dbux/cli. * It currently has limited configuration, but we hope for more in the future.
    • If you use a bundler, you might want to configure caching for it as well, especially to reduce cold-start overhead.
  • When executing a lot of stuff (e.g. long loops or high FPS games etc), things will get slow:
    • A simple loop with 1 million+ iterations will already get pretty slow. It generates 100+MB of serialized data and significantly increases memory pressure on @dbux/runtime as well as Dbux VSCode Extension.
    • For the same reason, Dbux probably is not yet able to cope with a 30+FPS game running for more than a few seconds.
  • When running a program with Dbux enabled, and also running it in debug mode in Node (i.e. --inspect or --inspect-brk), things slow down even worse. When things get too slow, you might want to consider using the Run button instead of the Debug button, and use the Dbux built-in features for debugging; unless there are some features in the traditional debugger that you just cannot live without in some specific circumstances.
  • Recording of large arrays and objects is limited, according to some (currently hardcoded) SerializationLimits, to be found in @dbux/runtime/src/data/valueCollection.js.
note

Improving performance and adding performance enhancing mechanisms is future work.

Improving Performance

Main steps to take to improve performance:

  1. Join our Discord and share your story, so we can advise, and also consider what types of performance improvements are most wanted.
  2. Disable tracing of specific files, statements or expressions, if they are not important for your analysis.
  3. tracesDisabled can significantly improve performance because it only traces function executions, no more individual statements or values.
    • TODO: explain how

A Comment on Performance

Performance and scalability issues are often cited as the biggest problems for omniscient debuggers. However, as Henry Liebermann pointed out in reference to his omniscient debugger (called ZStep 95) in 19971: "Even in an extremely large program, where keeping a complete history is infeasible, judicious testing can often isolate a fragement of the code which is not too large to run ZStep on. Nevertheless, we admit that there may be bugs that appear only after long runs involving large amounts of code, and so our techniques may be inappropriate in these cases. However, we conjecture that the vast majority of bugs are relatively shallow, and the productivity improvements from finding".

We believe, this applies to any omniscient debugger. While even large applications can be debugged with it, Dbux and its omniscient peers will falter when confronted with bugs in applications with high event frequency, such as games or algorithms with long-running loops. In order to make better use of Dbux in those cases, you (for now) need to first manually narrow down the bug to a shorter test case or short manual test run, before starting to use Dbux on them.

TODO: Some Results

TODO: provide some numbers