4 ms·

what's the advantage of using perf over valgrind? I've never really managed to get it working (it hooks into the kernel and inevitable some part of it fails for

what's the advantage of using perf over valgrind? I've never really managed to get it working (it hooks into the kernel and inevitable some part of it fails for me) - but maybe I'm missing out on something? I understand it probably handles mutithreading better and probably has a much better performance - but is that really it?

aksx 10y ago
valgrind had a bunch of stuff like massif, callgrind and memcheck but none of them (AFAIK) tell you how long a function call took, and point out the area of code taking too much time, which perf does.
- kazinator 10y ago
  Years ago I made a little C++ class for this. You could declare { tracer tr(function, ...) timer ti(tr, milliseconds); the constructor of the timer would sample and record the time. The destructor would sample the time again, and if it was over the specified milliseconds, it would log a diagnostic into the tracer.
- JDevlieghere 10y ago
  Indeed, because this wouldn't make much sense given the tenfold slowdown. Callgrind collect information about how many instructions were executed and who has been calling who. It's just a different profiling metric. I love valgrind/callgrind and it has proven extremely valuable. As always, choose the right tool for the job.
crazy2be 10y ago
The performance is way better. Callgrind/cachegrind operates as a cpu-level emulator (i.e. software emulating individual CPU instructions), while perf is a sampling profiler. This means you lose ~0 performance using perf, but at least ~10x performance using callgrind/cachegrind. There is also the advantage that perf is really testing the actual code on the real hardware. This can get important if you are trying to design code that is cache-aware. Although, with cachegrind, you can set what kind of emulated cache parameters you want, I'm not sure how well this emulates the real hardware, especially if you have multiple threads with cache conflicts.
larve 10y ago
It also samples the whole system, including the kernel. In embedded programming, a significant part of your application's time might be spent in some kernel routines, or servicing interrupts, and perf makes it extremely easy to figure it out. It can also trace arbitrary counters, even probes that the user can define. So for example, I can sample the number of bytes received over USB or other metrics like this. Tremendously useful. edited: typo
mfukar 10y ago
perf and valgrind have different purposes.

aksx 10y ago

valgrind had a bunch of stuff like massif, callgrind and memcheck but none of them (AFAIK) tell you how long a function call took, and point out the area of code taking too much time, which perf does.

kazinator 10y ago
Years ago I made a little C++ class for this. You could declare { tracer tr(function, ...) timer ti(tr, milliseconds); the constructor of the timer would sample and record the time. The destructor would sample the time again, and if it was over the specified milliseconds, it would log a diagnostic into the tracer.
JDevlieghere 10y ago
Indeed, because this wouldn't make much sense given the tenfold slowdown. Callgrind collect information about how many instructions were executed and who has been calling who. It's just a different profiling metric. I love valgrind/callgrind and it has proven extremely valuable. As always, choose the right tool for the job.

crazy2be 10y ago

The performance is way better. Callgrind/cachegrind operates as a cpu-level emulator (i.e. software emulating individual CPU instructions), while perf is a sampling profiler. This means you lose ~0 performance using perf, but at least ~10x performance using callgrind/cachegrind. There is also the advantage that perf is really testing the actual code on the real hardware. This can get important if you are trying to design code that is cache-aware. Although, with cachegrind, you can set what kind of emulated cache parameters you want, I'm not sure how well this emulates the real hardware, especially if you have multiple threads with cache conflicts.

larve 10y ago

It also samples the whole system, including the kernel. In embedded programming, a significant part of your application's time might be spent in some kernel routines, or servicing interrupts, and perf makes it extremely easy to figure it out. It can also trace arbitrary counters, even probes that the user can define. So for example, I can sample the number of bytes received over USB or other metrics like this. Tremendously useful. edited: typo

mfukar 10y ago

perf and valgrind have different purposes.