Resources
Undo Performance Benchmarks
The table below shows benchmarks of Undo’s recording technology on several common applications, showing:
- Runtime (native) – the original workload, running without recording
- Runtime (record) – the same workload, recorded by Undo
Once a deterministic recording has been captured by Undo, a bug can be efficiently time travel debugged to resolve critical issues with orders of magnitude less engineering time.
Workload |
Runtime (native) |
Runtime (record) |
Overall slowdown |
Per-thread slowdown |
| Mixed syscall workload
sqlite – 100,000 insertions |
3.8s | 11.1s | 2.9x | 2.9x |
| Compute-intensive workload
gzip – 128MB input file |
4.8s | 7.3s | 1.5x | 1.5x |
| Compute-intensive workload
ffmpeg – VP9 to H264 transcode |
1.8s | 9.8s | 5.6x | 1.4x |
In these results, the per-thread slowdown is kept low (at 1.4 – 2.9x) by Undo’s dynamic just-in-time instrumentation, which captures only the minimum data required to replay the process.
Multithreaded workloads may see an additional overall slowdown since Undo serializes their execution (using pre-emptive scheduling, so that race conditions are still reproduced). Compute-intensive applications like ffmpeg (shown above) show the most overhead due to this serialization. Common uses of threads for IO concurrency show less impact.
Want to talk an engineer about Undo and whether it’ll work in your environment? Book a demo below.