3 ms·
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 d
by 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 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.