Re: [RFC] Deprecating mtrace?

[OndÅej BÃlka <neleai at seznam dot cz>]

On Mon, Nov 04, 2013 at 09:29:47AM +0100, Fabrice Bauzac wrote:
> Valgrind is too slow for large CPU-intensive programs.
>
Citation needed.

We are talking about relative valgrind/mtrace performance so please post
a real world testcase where mtrace is faster than valgrind.

A simple example of contrary is gcc. Consider following program. That
enables mtrace.

#include <mcheck.h>
void __attribute__((constructor)) init(){
  mtrace();
}

Now compiling it is fast.

$ time gcc -O3 m.c -fPIC -shared

real	0m0.038s
user	0m0.024s
sys	0m0.004s

For valgrind a overhead is mostly a additive constant, as when I compile
a bigger files relative overhead goes down but we take this as example.

$ time valgrind gcc -O3 m.c -fPIC -shared

real	0m0.690s
user	0m0.652s
sys	0m0.028s

Now when we try to use mtrace on this trivial file overhead is bigger
than valgrind.

LD_PRELOAD=./m.so MALLOC_TRACE=x time gcc -O3 m.c -fPIC -shared
1.66user 0.01system 0:01.70elapsed 98%CPU (0avgtext+0avgdata
9788maxresident)k
0inputs+2704outputs (0major+6735minor)pagefaults 0swaps

Now for big  input take glibc iconvdata/big5.c file.

$ time gcc -O3 iconvdata/big5.c

real	0m0.619s
user	0m0.520s
sys	0m0.084s

valgrind is three times slower which is acceptable.

$ time valgrind gcc -O3 iconvdata/big5.c

real	0m1.497s
user	0m1.356s
sys	0m0.136s

but when I try a mtrate it has again unacceptable overhead.

LD_PRELOAD=m.so MALLOC_TRACE=x time gcc -O3 iconvdata/big5.c

45.47user 0.31system 0:46.12elapsed 99%CPU (0avgtext+0avgdata
19472maxresident)k
0inputs+60592outputs (0major+16918minor)pagefaults 0swaps

 
> 2013/11/4 Alfred M. Szmidt <ams@gnu.org>:
> > The usage cases between valgrind and mtrace are so vastly different
> > that which is better is a matter of what you are doing, there several
> > cases when valgrind simply cannot do the job.  For example,
> > enabling/disabling leak tracing on a already running process, or when
> > you are only interested in parts of the code where you might suspect a
> > leak in a long running process, or enable tracing automatically when
> > you hit some trigger (e.g. memory usage exceeding some limit).  Two
> > different tools, with two different goals, mtrace for programmatically
> > doing traces, and valgrind for interactive usage.