This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Deprecating mtrace?

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(){

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=./ MALLOC_TRACE=x time gcc -O3 m.c -fPIC -shared
1.66user 0.01system 0:01.70elapsed 98%CPU (0avgtext+0avgdata
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. MALLOC_TRACE=x time gcc -O3 iconvdata/big5.c

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

> 2013/11/4 Alfred M. Szmidt <>:
> > 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]