Some steps from a typical malloc call will show you how much work is performed here:
A program does request memory from the heap with int* ptr = (int*) malloc(1024 * sizeof(int)); . It expects a pointer back which points to a newly allocated areas on the heap which is at least big enough to hold 1024 integer values, no matter how big an integer on this platform is. If the program would ask for (1024 * 2) bytes it would assume 16 bit integer values and would not be portable to other hardware.
The reason for malloc being a very expensive call has many facets. First, finding the proper area needs a clever memory organisation by malloc so that it will find those pieces fast. Remember, malloc does not know how much memory will be request. Could be one byte, could be thousands. The next problem appears when the current heap size becomes too small. Now malloc must ask the Operating System for more heap space, using a brk or sbrk system call. Now the operating system allocates physical memory and maps it into the process address space which belongs to the heap. Frequent allocations are expensive if done in small sizes, but how should malloc know?
. And last but not least when the memory is returned malloc has to try to reduce fragmentation of memory space. Otherwise it will not find a piece of memory big enough to satisfy a request even though enough small pieces would be available. A lot of list processing.Just to top it off: If this is a multi-threaded program chances are that malloc needs to protect its heap data structures from being corrupted by threads trying to allocate memory in parallel. This means expensive semaphore and monitor operations.