[Valgrind-developers] Re: mega-merge status

[Nicholas N. <nj...@ca...>]

On Thu, 14 Nov 2002, Julian Seward wrote:

> > > - 27-nvalgrind -- is this really actually needed?  Do you have some
> > >   performance numbers indicating, when running natively, that the 12-insn
> > >   sequence really causes significant performance loss?
> >
> > I doubt there's a good technical justification for it, but when trying
> > to convince people to use Valgrind, I've found it most useful to be able
> > to say "you can compile out all the Valgrind annotations for production
> > builds".  It's just one less argument for people to make.  And when
> > describing the client callback mechanism to people, they invariably ask
> > whether the callbacks can be compiled out within about 1 to 2
> > milliseconds.
>
> Yes, I thought I was being a bit churlish not merging this.  I'll merge
> it (not right now, but later).

One question:  as implemented by the patch, is NVALGRIND really analogous
to NDEBUG?  AIUI, assertions are on by default, but if you #define NDEBUG
they get turned off.

Patch 27 looks to me like the behaviour is the opposite -- client requests
are off by default but get turned on if you #define NVALGRIND.
Should the #ifndef be a #ifdef?

A general note:  I think this patch is a good thing.  At a research group
talk I gave about Valgrind one person seemed upset by the potential
performance effects of the magic sequence;  "it could be in an inner
loop!"  he cried, more or less.  People are very touchy about these
things, as Jeremy said it's one less argument people can make.

N