14 ms·

While I agree with author that record-and-replay debuggers are nice, I don't think they will ever entirely go away. Those debuggers are ultimate "trace loggers"

by theamk 6y ago

While I agree with author that record-and-replay debuggers are nice, I don't think they will ever entirely go away. Those debuggers are ultimate "trace loggers", logging each statement and variable -- and thus they have inevitable overhead. I can see how replay debuggers work with programs like Firefox, where you start with a few megabytes of input data and have a working set of a few hundred megs -- but there are programs with much higher memory/io usage out there. Something as simple as "download a few gigs of data from internet and calculate its hash" will require enough trace to record all data downloaded, which would make the overhead huge.

db48x 6y ago
A program running under RR generally only runs about 40% slower than normal, which is often unnoticeable. The recordings are usually smaller than you would expect too; the largest one I have is 74GB, though that was because the program read in a whole lot of data. I didn’t record it reading in the whole 400+GB file… most of them are under 200MB. Actually, about 60% of them are less than a single megabyte. There must be a power–law thing going on there. Still, disk space is cheap; I may have to delete that recording one day but there’s plenty more disk space available.
- simiones 6y ago
  As far as I understand, rr forces your program to run single-threaded while recording, so the performance overhead would be arbitrarily high depending on your degree of actual parallelism.
  - db48x 6y ago
    Not exactly. Your program will still have threads, but RR intercepts the pthreads API and runs all your threads in a single OS thread; it handles context switches between your threads as if your computer only had a single CPU core. This does mean that the overhead can be much higher than 40%! The 40% number is for a program like Firefox, that might jump up to 16 active threads to render a webpage, but also had to idle for 50ms while it waited for the TCP connection to start up. I found that it was also a reasonable estimate for Reposurgeon, which is written in Go and uses concurrency during some repository operations, and when doing garbage collection. Other parts cannot be parallelized at all, so it balances out. I never measured that very precisely though; it would take anywhere from seconds to minutes to run a test without RR (depending on the data I loaded, etc), and only somewhat longer with RR.
Jfuvjrnfjxje 6y ago
> Those debuggers are ultimate "trace loggers", logging each statement and variable -- and thus they have inevitable overhead. rr only logs sources of non-determinism, such as system calls (which includes I/O). Then all the deterministic state of the program is reconstructed at runtime using the recorded non-determinism. So having lots of state doesn't necessarily affect trace size but you're right that lots of I/O will.

by theamk 6y ago

db48x 6y ago

A program running under RR generally only runs about 40% slower than normal, which is often unnoticeable. The recordings are usually smaller than you would expect too; the largest one I have is 74GB, though that was because the program read in a whole lot of data. I didn’t record it reading in the whole 400+GB file… most of them are under 200MB. Actually, about 60% of them are less than a single megabyte. There must be a power–law thing going on there. Still, disk space is cheap; I may have to delete that recording one day but there’s plenty more disk space available.

simiones 6y ago
As far as I understand, rr forces your program to run single-threaded while recording, so the performance overhead would be arbitrarily high depending on your degree of actual parallelism.
- db48x 6y ago
  Not exactly. Your program will still have threads, but RR intercepts the pthreads API and runs all your threads in a single OS thread; it handles context switches between your threads as if your computer only had a single CPU core. This does mean that the overhead can be much higher than 40%! The 40% number is for a program like Firefox, that might jump up to 16 active threads to render a webpage, but also had to idle for 50ms while it waited for the TCP connection to start up. I found that it was also a reasonable estimate for Reposurgeon, which is written in Go and uses concurrency during some repository operations, and when doing garbage collection. Other parts cannot be parallelized at all, so it balances out. I never measured that very precisely though; it would take anywhere from seconds to minutes to run a test without RR (depending on the data I loaded, etc), and only somewhat longer with RR.

Jfuvjrnfjxje 6y ago

> Those debuggers are ultimate "trace loggers", logging each statement and variable -- and thus they have inevitable overhead. rr only logs sources of non-determinism, such as system calls (which includes I/O). Then all the deterministic state of the program is reconstructed at runtime using the recorded non-determinism. So having lots of state doesn't necessarily affect trace size but you're right that lots of I/O will.