3 ms·
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 expe
by 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 agoAs 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 agoNot 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.