🚀 go-pugleaf

Windows has limits on the number of handles it will provide and 
Windows allocation/deallocation calls are slow.

The runtime library memory allocation functions encapsulate Windows 
allocation calls, allocating a chunk when called, dolling out a piece 
of that block of  the requested size to you and leaving the rest as 
available for subsequent calls.  Later when free is called, the freed 
block will most likely to be made available for future allocation 
calls instead of being given back to the operating system.

.  Ed

> Azazello wrote in message
> news:4165469c$1@newsgroups.borland.com...
>
> Hi there,
>
> Haven't been here for a while, glad to see that TeamB is still
> active. You guys rock! ;)
>
> Now to the topic. I've been playing with multithreading under
> Win32 and as a part of it ran into a question about optimal
> memory allocation, which provoked me to test speed of
> different memory allocation functions. The results were,
> should I say, interesting, and though most of you ran these
> tests yourself, I'll take the liberty to share them.
>
> Setup: 10000 cycles of allocation/deallocations of
> 0x2000 bytes (8K) ; Performance Counter used as timer.
> ...
> 1. Can someone explain to me how malloc (serialized
> function, by the way) can be 33 (SIC!) times faster than
> heap functions and 11 times faster than VirtualAlloc (ok,
> VirtualAlloc zeros memory, but still, calloc is 2 times
> faster)?
> 2. Why Non-serialized/non-growable heap is twice slower
> than serialized/growable heap? Shouldn't it be other way
> around?
> 3. malloc seems to be too good to be true, so where is the
> catch? What does not malloc do compare to other functions?