Re: Disadvantages of malloc()

Would you mind to elabrate further what overheads there are?

You have to keep track of what has been allocated (size and location). Blocks are allocated/freed in any order, so free memory could be fragmented. This means you also have to keep track of each free segment (size and location). Say your system has 256 bytes or less of RAM so size and location can be one byte each. Remember also that RAM also holds statically allocated variables and your stack. :-)

Reply to
Gary Kato
Loading thread data ...

There are at least three problems:

  1. Fragmentation

A simple example:

Let's say you have 1000 B of memory. You happen to allocate it in three 300 B chunks. Everything goes fine, you have allocated the first 900 B. Then you release (free) the first and the last piece. Now you have 700 B of free memory; 300 B in the beginning and

400 B in the end of the memory. When you try to allocate 500 B, you cannot. There is enough free memory, but not enough in one piece. Your memory has a fragmentation problem.

There are workarounds. If your memory manager is able to separate logical (virtual) and physical addressing, everything goes fine, because it can rearrange the memory without you noticing it. However, these tricks are not very reasonable if you have only a small amount of memory.

  1. Overhead

You need to have some memory allocation information in order to realize dynamic memory allocation. This information takes some space.

  1. Possibility of overallocation

This is more a programming style issue, but if you use dynamic memory allocation, you may end up in a situation where malloc() returns NULL. This may happen due to fragmentation or just simply because you run out of memory. What happens then? You cannot wait for someone to free some memory, but usually you cannot do anything without the memory.

If you use static memory allocation, things are more predictable. You will notice if you don't have enough memory.

So, avoiding dynamic memory allocation is a very good idea in small systems. The border between a small and a large system is somewhat difficult to draw, but I'd say dynamic memory allocation would need dozens of kilobytes of data RAM. Most things can be done without, and the predictability is much better.

- Ville

--
Ville Voipio, Dr.Tech., M.Sc. (EE)
Reply to
Ville Voipio

It depends on what you mean with small memory. If it is in the order of a couple of hundred bytes, then the overhead of keeping track of allocated memory takes up a significent portion of the available memory. If you have at least couple of kilobytes or more, then heap fragmentation becomes the biggest problem. (That is if there are no allocation and deallocation bugs in the program) Heap fragmentation occurs when blocks are allocated (malloc) and deallocated (free) in different order. The program might allocate blocks of say: 100, 200, 100, 500 bytes in order. It then de-allocates the two 100 byte blocks. If in the original allocation most of the heap had been allocated, then if you try to allocate a block of 200 bytes, malloc will fail even though the physical memory is available. Fragmentaion might occur of long periods and your device might only fail after days or weeks of operation. It is often better to statically allocate the maxim memory that will be needed by each routine.

Regards Anton Erasmus

Reply to
Anton Erasmus

The easiest way to avoid this (external) fragmentation is to merge adjacent free blocks of memory during the freeing process. It is relatively easy to implement this and if you have no MMU, that is all you can do. If you use memory pools, there is no external fragmentation, but internal fragmentation.

At the minimum, you need the size of the allocated block. But if you use memory pools or allocate many blocks of the same size, you can get a per block overhead of 0.

Yes, if you allocate more memory than you have, this is generally a problem ;-) But it is true, users of a dynamic memory API tends to overlook this.

I dont't think so. A good dynamic memory allocation library (take a look onto the Amiga memory API, it is ingenious) and a careful use of its features results in better and more readable code and consumes only a few bytes of RAM. But I agree, if you have only 1kB of RAM and your code is 2kB, its maybe not worth the affort.

Regards,

--
Bernhard Roessmann
Don't Fear The Penguins!
Reply to
Bernhard Roessmann

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.