On Tue, Oct 2, 2012 at 9:16 AM, John Reiser <[email protected]> wrote: > > Not necessarily.
Yes, necessarily. > In *your* favorite "modern" CPU, a transfer of control > to a non-local destination can cost 15 times as much as a local test-and- > skip-over, depending on branch prediction and Icache misses. True but irrelevant. As I said, delete of NULL is guaranteed by the language to be a no-op; i.e., when the pointer is null, the destructor is not invoked. The compiler emits an inline null check even with optimization disabled. > Particularly > if 'delete' has not been called recently, then code which uses a local > guard might be faster. No, the code with your own guard is never faster under any circumstances. At best it can be the same speed if your compiler is smart enough to recognize the test as redundant. > It is also true that prevalent compilers don't make the obvious optimization > of removing the test. Also wrong. The current GCC (4.7.1) omits the redundant null check when optimization is enabled. > An unconditional breakpoint > is much faster (no dynamic cost unless triggered) than a conditional one. Yes, let's all make our code longer, harder to read, and slower, just in case somebody inserts a breakpoint there and wants it to run a few nanoseconds faster under the debugger. I always heard engineering is about trade-offs; this must be one of those times. John, I know how much you love to argue with me, but you would save others some time if you would check your facts first. - Pat ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
