3 ms·
WinDbg uses a instruction-level emulation time travel implementation, so incurs the 10-20x slowdown associated with that technique. rr uses a replay-record time
by Veserv 2y ago
WinDbg uses a instruction-level emulation time travel implementation, so incurs the 10-20x slowdown associated with that technique. rr uses a replay-record time travel debugging implementation, which can incur far less overhead when done correctly. Last I saw, rr has overhead in the 2x slowdown range and, if I remember correctly, I have seen a different record-replay time travel debugger in the 10% range.
10% is 100x cheaper than WinDbg and cheap enough to leave on all the time in production. That is a game-changer.
- forrestthewoods 2y ago> 10% is 100x cheaper than WinDbg If you’re gonna throw around numbers like this you need to cite an actual tool not “if I remember correctly there exists a unicorn”.
- dzaima 2y agoMore precisely, rr records just system calls & interrupts, so its overhead is largely proportional to how syscall-heavy and multithreaded your code is. If it's single-threaded and mostly just pure computation, you can easily see ~0% slowdown, with replay at the exact same speed. (a quick simple test shows that 'mmap'+'munmap' of a file is 0.5ms, vs 0.006ms outside rr; but many syscalls are buffered in rr's userspace and thus way faster (e.g. a 'stat' on the same file path is only like 300ns slower than native))