|
From: Nicholas N. <nj...@ca...> - 2002-11-14 09:36:56
|
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 |