On lundi 3 avril 2023 23:46:46 CEST Nicholas Nethercote wrote: > On Mon, 3 Apr 2023 at 21:36, David Faure <fa...@kde.org> wrote: > > But then, what's the difference between `cachegrind --cache-sim=no` > > and `callgrind`? > > > > https://accu.org/journals/overload/20/111/floyd_1886/ says > > "The main differences are that Callgrind has more information about the > > callstack whilst cachegrind gives more information about cache hit rates." > > > > Wouldn't one want callstacks? (if this means stack traces). > > I know I must be missing something, thanks for enlightening me. > > Callgrind is a forked and extended version of Cachegrind. It also simulates > a cache, with a slightly different simulation to Cachegrind's. The fact > that both tools exist is due to historical reasons; if starting from > scratch today you wouldn't deliberately split them.
Thanks for the information. This is indeed confusing - like anything that is "due to historical reasons" ;-) > Call stacks are often useful (I regularly use Callgrind as well as > Cachegrind) but they aren't always necessary. Without them, Cachegrind runs > faster than Callgrind and produces smaller data files. Cachegrind also > supports diffing and merging different files, while Callgrind does not. OK. I thought call stacks were mandatory for any tool to be useful (they certainly are for KCachegrind (*)), but I now found the documentation on cg_annotate. But then, with no cache simulation and no call stacks, what's left in `cachegrind --cache-sim=no`? (*) This naming adds to the confusion: kcachegrind requires callgrind, it can't work with cachegrind... I know, historical reasons :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
