C++: delete vs. free and performance

Question

1. Consider:

   char *p=NULL;
   free(p) // or
   delete p;
   

   What will happen if I use free and delete on p?

2. If a program takes a long time to execute, say 10 minutes, is there any way to reduce its running time to 5 minutes?

Solution 1

Some performance notes about new/delete and malloc/free:

malloc and free do not call the constructor and deconstructor, respectively. This means your classes won't get initalized or deinitialized automatically, which could be bad (e.g. uninitalized pointers)! This doesn't matter for POD data types like char and double, though, since they don't really have a ctor.

new and delete do call the constructor and deconstructor. This means your class instances are initalized and deinitialized automatically. However, normally there's a performance hit (compared to plain allocation), but that's for the better.

I suggest staying consistent with new/malloc usage unless you have a reason (e.g. realloc). This way, you have less dependencies, reducing your code size and load time (only by a smidgin, though). Also, you won't mess up by free'ing something allocated with new, or deleting something allocated with malloc. (This will most likely cause a crash!)

Solution 2

Answer 1: Both free(p) and delete p work fine with a NULL pointer.

Answer 2: Impossible to answer without seeing the slow parts of the code. You should profile the code! If you are using Linux I suggest using Callgrind (part of Valgrind) to find out what parts of the execution takes the most time.

Solution 3

Question one: nothing will happen.

From the current draft of ISO/IEC 14882 (or: C++):

20.8.15 C Library [c.malloc]

The contents [of <cstdlib>, that is: where free lives,] are the same as the Standard C library [(see intro.refs for that)] header <stdlib.h>, with the following changes: [nothing that effects this answer].

So, from ISO/IEC 9899:1999 (or: C):

7.20.3.2 The free function

If [the] ptr [parameter] is a null pointer, no action occurs.

From the C++ standard again, for information about delete this time:

3.7.4.2 Deallocation functions [basic.stc.dynamic.deallocation]

The value of the first argument supplied to a deallocation function may be a null pointer value; if so, and if the deallocation function is one supplied in the standard library, the call has no effect.

See also:

• What is the difference between new/delete and malloc/free?
• What happens when you try to free() already freed memory in c?

Solution 4

Nothing will happen if you call free with a NULL parameter, or delete with an NULL operand. Both are defined to accept NULL and perform no action.

There are any number of thing you can change in C++ code which can affect how fast it runs. Often the most useful (in approximate order) are:

• Use good algorithms. This is a big topic, but for example, I recently halved the running time of a bit of code by using a std::vector instead of a std::list, in a case where elements were being added and removed only at the end.
• Avoid repeating long calculations.
• Avoid creating and copying objects unnecessarily (but anything which happens less than 10 million times per minute won't make any significant difference, unless you're handling something really big, like a vector of 10 million items).
• Compile with optimisation.
• Mark commonly-used functions (again, anything called more than 100 million times in your 10 minute runtime), as inline.

Having said that, divideandconquer is absolutely right - you can't effectively speed your program up unless you know what it spends its time doing. Sometimes this can be guessed correctly when you know how the code works, other times it's very surprising. So it's best to profile. Even if you can't profile the code to see exactly where the time is spent, if you measure what effect your changes have you can often figure it out eventually.

Solution 5

On question 2:
Previous answers are excellent. But I just wanted to add something about pre-optimization. Assuming a program of moderate complexity, the 90/10 rule usually applies - i.e. 90% of the execution time is spent in 10% of the code. "Optimized" code is often harder to read and to maintain. So, always solve the problems first, then see where the bottlenecks are (profiling is a good tool).

View more solutions