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 taking more time for execution, suppose 10 minutes, is there any way to reduce its running time to 5 minutes?

Answer 1

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.

Answer 2

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.

Answer 3

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).

Answer 4

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?

Answer 5

As others have pointed out deleting (or freeing) a NULL pointer will not do anything. However if you had allocated some memory then whether to use free() or delete depends upon the method you used to allocate them. For example, if you had used malloc() to allocate memory then you should free() and if you had used new to allocate then you should use delete. However, be careful not to mix the memory allocations. Use a single way to allocate and deallocate them.

For the second question, it will be very difficult to generalize without seeing the actual code. It should be taken on a case by case basis.

Answer 6

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 free do call the constructor and deconstructor. This means your classes 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 dependancies, 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!)

Answer 7

Good answers all.

On the performance issue, this provides a method that most can't imagine will work, but a few know it does, surprisingly well.

The 90/10 rule is true. In my experience, there usually are multiple trouble spots, and they usually are at mid-levels of the call stack. They often are caused by using over-general data structures, but you should never fix something unless you've proven that it actually is a problem. Performance problems are amazingly unpredictable.

Fixing any single performance problem may not give you the speedup you need, but each one you fix makes the remaining ones take a larger percentage of the remaining time, so they become easier to find. The speedups combine in a compounded fashion, so you may be surprised at the final result.

When you can no longer find significant problems that you can fix, you've done about as well as you can. Sometimes, at that point, a redesign (such as using code generation) can set off a further round of speedups.