Re: Cost of deleting a null pointer
On Dec 1, 4:29 am, "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];
That can't compile. You need T* tlist[18];
I'll presume that's the case.
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.
I would like to see details on that measurement. Optimized build or
not? What hardware? (I mean, on recent hardware, that call to operator
delete is going to get cached and fly like a hawk.)
His assumption was
that all the destructor and freeing logic was being gone through
even when the pointer was null.
That's of course not possible. How can you call a destructor on 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.
Is this just a Quality of Implementation issue, or is it reasonable to
expect that deleting a null pointer should be expensive?
My bet is on wrong measurement.
Otherwise, in a sane implementation, the difference between two
variants is the price of a call to operator delete. Operator delete
must be something like this:
void operator delete(T* p)
{
if (!p) return;
p->~T();
free(p); // another "if (!p) return" here, but that's never reached.
}
So, for "most are null", there's an immediate return.
I think operator delete is not inlined in common implementations (it's
an if and two calls, one of them possibly virtual).
Goran.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]