I'm implementing a system in C, implemented partially as a library. The library does most of the memory management itself, with the application layer just having to call
*_destroy functions on the top-level objects.
While checking for memory leaks, I noticed that the number of calls to
malloc seemed quite high, relative to the size of the application code. The performance of the code seems fine, but I've been bitten by "fast enough" code before when trying to scale.
The number of allocations roughly matches the number of objects created, including child objects of the top-level ones. So creating a single top-level object might trigger 7 malloc calls, since it needs one for itself and then a couple for it's children that may also need a few children.
Unfortunately, I'm relatively new to C programming, though generally experienced as a programmer, and have no idea whether or these numbers are normal or not.
So what would a good rule-of-thumb be for number of allocations? I know that less would generally be better, but changing the code to allow it would introduce complexity that I'm not willing to add without a significant increase in performance.
Also, should I worry about the performance of
malloc/free or is that the realm of real-time performance (games etc.)?