Re: Cost of deleting a null pointer
On Nov 30, 10:29 pm, "A. McKenney" <alan_mckenn...@yahoo.com> wrote:
Recently, someone was doing some profiling of our code, and found that
code essentially like the following was taking far more time than
expected:
class T { /* .... */ };
T tlist[18];
...
void reset()
{
for ( int i = 0; i < 18; ++i )
{
delete tlist[i];
tlist[i] = 0;
}
}
In most cases, all the elements of tlist were null.
He found that if he replaced
delete tlist[i];
with
if ( tlist[i] ) delete tlist[i];
it sped the function up by about a factor of 30. His assumption was
that all the destructor and freeing logic was being gone through
even when the pointer was null.
We all thought this was pretty surprising, since "delete p" is
supposed to
be a no-op if p is a null pointer. In fact, I'd assumed that an
optimizing
compiler might put something like this "if" statement in anyway.
I had assumed the same thing when I experienced something similar a
few years ago. See below.
Is this just a Quality of Implementation issue, or is it reasonable to
expect that deleting a null pointer should be expensive?
My project involved processing about 30GB of data. The processing
took 1 hour, 38 minutes to complete on the fastest computer I had, and
I wanted to get it under an hour, so I went snooping around for
opportunities to optimize. To my surprise, the compiler was not
checking to see if the argument of delete() was 0 before invoking the
machinery that effects delete(). So I added a test, as you did above,
and the difference was dramatic. I do not remember if it was 30x, nor
if I was using Debug or Release code (on Visual Studio 2008) were the
Debug configuration might add some extraneous fat just before
invocation, but I do remember that the difference was so great that I
made a note to self: "Explicitly test for 0 on delete from now on." I
also recall, after a thorough examination of the dis-assembly and some
reflection, arriving at the conclusion that the compiler writer was
very-well cognizant of what s/he had done and deliberately designed it
that way. Unfortunately, how I arrived at this conclusion, I cannot
remember...but...
One might conclude that, if the compiler writer were to adopt the
policy of injecting a test for 0 before each invocation of delete(),
there would be a penalty, however small, and this automatic injection
would preempt the possibly of optimization, whereas, by not
subscribing to a policy of automatic injection, it leaves open the
possibility that the programmer himself may make the test.
I guess checking-for-0-before-actual-call-to-delete is a good
candidate for a command-line flag.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]