High usuage of malloc and free

[Dave.Rogers]

I am using a Model, View, Controller design pattern. I will also be having high amount of memory block pointers going through thread safe queues. Malloc of memory at the sender and then free at the receiver end. I have estimated over 100,000 of malloc/free for every 24hrs that will last 4 months. It's a life test fixture with high amount of measurements.

So the question is:

 Is it better to implement a type of SLAB memory manager instead of all the thrashing by calling malloc/free 100k for every 24hrs?

Thank you

Dave Rogers

[gdargaud]

If your mallocs have highly variable sizes, you'll end up with fractionned memory and it's possible to be in situation where 1% heap use blocks allocation of the rest. It's nothing specific to LabWindows, it's just simple C. In that case, yes, you'd need a more intelligent allocator.

But if your mallocs are always the same size, there shouldn't be a problem, even at 99% full.

[Dave.Rogers]

Thank you for the good information.  Along with that what about the amount of time consumed for all the  malloc/frees ? I have read some info on memory managers. Supposedly with using a specialized memory manager that is tuned for your specific needs solves not only the memory issues but also consumes less time, but I haven't done any experiments to prove this out.

Thank you again

Dave Rogers

[rolfk]

While malloc() and free() certainly require some CPU resources each time, writing your own memory manager is a project that you should think very hard and very long about. A memory manager that is not working perfectly in 100% of the cases, under every circumstance even when your machine is running at heavy load because of other threads and processes consuming performance, and of course being 100% threadsafe, you have a much bigger problem than a slow memory allocation performance. 100k malloc/free in a 24 hour period isn't anything that should bog down a modern system in any way. It gets problematic if you start to have 1000 or more such allocations/deallocation cycles per second. Your 100k/24h comes down to a little over 1 allocation/deallocation per second and that will certainly not tax any modern system at all.

That said if your code can reuse buffers because their size remains the same between each run I would definitely try to use that to reduce the performance impact. But worrying about writing your own memory manager because of the memory management requirements you outlined, is not only premature optimization but really outright looking for an expensive solution of a problem you don't even have.