This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Deprecating mtrace?
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Fabrice Bauzac <libnoon at gmail dot com>
- Cc: ams at gnu dot org, joseph at codesourcery dot com, libc-alpha at sourceware dot org
- Date: Mon, 4 Nov 2013 10:34:04 +0100
- Subject: Re: [RFC] Deprecating mtrace?
- Authentication-results: sourceware.org; auth=none
- References: <20131103185737 dot GA29145 at domone dot podge> <Pine dot LNX dot 4 dot 64 dot 1311031859260 dot 16907 at digraph dot polyomino dot org dot uk> <20131103191754 dot GA29265 at domone dot podge> <E1Vd3d0-0005vw-59 at fencepost dot gnu dot org> <20131103220632 dot GC29825 at domone dot podge> <E1Vd7xe-0002K3-Pi at fencepost dot gnu dot org> <CAB6Q1a_a-Ko3jUowbp4A3QGYkWAxT-Ch4AL0BzZA-eD+QScB6w at mail dot gmail dot com>
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.