Should I free memory for a short lived program if memory footprint is not an issue?

Question

I have a program that does the following

1. Allocate memory (heap)
2. Do some processing
3. Allocate more memory (heap)
4. Do some processing

It does so a few times then exit.

I don't really care about the memory footprint of the program, only the execution time.

Would it be a bad thing not to free memory on the account that it might actually takes more time to process the free/delete than just skip it and move to next step.

In the end, the program will exit and it won't matter anymore.

I understand that the only way to be sure is to do some benchmarks on my computer, but I'm interested in the theoretical pros and cons.

NB: let's assume a modern OS that will cleanup the memory at exit.

Answer 1

Whether not releasing allocated memory will be a performance win or loss depends on your allocation patterns and how you use the memory. If you free, future mallocs will likely end up reusing the memory of previous mallocs. This can save time because that old memory will not have to be obtained from the OS and it will likely be in cache. Page faults and cache misses can slow things down quite a bit.

If you care about this, benchmark a freeing and not-freeing variant of your program.

Answer 2

There are a number of potential problems. Examples include;

• If you can't predict in advance how much memory is actually needed - which is among the most common reasons to use dynamic memory allocation - then your program may exhaust available memory (either due to exhausting system memory, or because the host operating system impose quotas on your program). After that, it may or may not run as fast as required, but (even ignoring timing concerns) will probably run incorrectly and produce incorrect results. It doesn't matter how much memory your host system has, or what quota the host system enforces for program it hosts - it is possible to exhaust that amount.
• Not all operating systems release memory as a program exits. And, among those that do, there is potential that the memory is not fully released - both due to bugs in the OS itself, and due to actions by your program (e.g. allocating resources that are shared with other programs). In such cases, if your program is run several times, you may find that the program (when run for the 32nd time [to pick a random number] or so) will inexplicably fail.
• As a program allocates more memory then, depending on how dynamic memory allocation is managed (e.g. data structures used by malloc()), allocations themselves can slow down if memory is not released. That can cause your program not to meet timing constraints as it allocates more memory. Releasing memory when no longer needed can alleviate such concerns (albeit with other effects, such as memory fragmentation).
• If you get into the habit of not releasing dynamically allocated memory, you may well also (for similar reasons of "efficiency") not bother to check if allocations succeed - after all, that takes time too. And that causes problems should allocations ever fail (e.g. abnormal program terminations, trashing memory, producing wrong results without warning, etc).

The bottom line is that allocating memory and not deallocating it is a very poor (and lazy) strategy if you care at all about program performance or timing. If you really care about program performance/timing, you will not actually dynamically allocate memory at all.

If you are using dynamic memory allocation, then you are better off releasing it when no longer needed, even if you don't care about memory footprint. Depending on circumstances, you may find the program runs either faster or slower if you release memory properly (it depends on numerous variables, including those I'm mentioned above, and more). And, should you ever need to reuse your code in a larger program - which, practically, happens more often than not in the real world - you are more likely to run into problems (memory concerns, performance concerns) if your code does not release memory properly.

Answer 3

Where are you allocating the memory?, the stack or the heap? In your case I would advice you allocate your stuffs on the stack (i.e Not using any memory allocation functions).

However, most OS de-allocates your share of the heap when your program exits. If you are using the heap, and your are using the modern C++ coding, you want to readup on Smart pointers.

Creating stack object has the lowest performance hit, and they are scope based (which is even cooler). The only cons is very limited space.

One other technique is to pre-allocate a chunk of memory initially on the heap; and manage the allocated space for usage, this common in Emulators.

Answer 4

This hardly depends on where you run the program, most modern OS will clear the memory allocated by a program on exit. So as long as you don't allocate big amounts, there should be no issue.

But if you work embedded this might not be true.

Edit: If the OS clears memory after execution then, the only issue might be that you allocate more than there is available. But as long as this doesn't happen I don't see an issue there. It is common practice for some programs nowadays.

Answer 5

You should always free all allocated memory before program termination for several reasons.

1. This is commonly considered best practice.
2. It is unclear whether there is any benefit (in terms of execution speed) from letting the run-time clean up after you.
3. This avoids memory leaks in case the run-time environment fails to collect all memory.
4. Should you ever extend this program or build on it, the memory leak may spread into other code.

Furthermore, in C++ you should avoid the need for 'manual' memory de-allocation and rely on RAII methods, such as provided by the standard library via its containers and smart pointers.