This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Deprecating mtrace?
- From: Markus Trippelsdorf <markus at trippelsdorf dot de>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Fabrice Bauzac <libnoon at gmail dot com>, ams at gnu dot org, joseph at codesourcery dot com, libc-alpha at sourceware dot org
- Date: Mon, 4 Nov 2013 10:58:01 +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> <20131104093404 dot GA4985 at domone dot podge>
On 2013.11.04 at 10:34 +0100, OndÅej BÃlka wrote:
> 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
You should use "--track-origins=yes --trace-children=yes" here to make
this a fair comparison.
--
Markus