Re: "does your knowledge of your application's memory needs and memory performance trump all the effort and knowledge that went into creating the memory allocat

Re: "does your knowledge of your application's memory needs and memory performance trump all the effort and knowledge that went into creating the memory allocator of the operating system you're using?". Almost always. You can almost always answer the question "am I going to need memory again after this free()". If memory is tied to a request or some other object you almost always know that. You can almost always make a good guess at how much data a repeated operation will need, thus how much memory to reuse. You almost always know the benefit of caching data in memory that is otherwise on disk. Often the OS is better at this than the developer thinks! You almost always know if data is likely to be needed in memory again. When you free() you lose the space and the data. Quite often you can benefit from a managed free() that you can ask for the memory again still populated if nothing else needed the space it in the end. You almost always know the security concequences of reusing memory. e.g. the OS cannot tell if calloc or malloc is needed. Secure(ish) allocators are a thing. You almost always know if a memory block might grow or is fixed size. You almost always know when you need an i/o buffer that can be reused. You almost always know if smart pointers are beneficial or not. In C its perfectly normal to allocate on the stack rather than the heap because you know better than malloc(). You often know more than the allocator about memory alignment. I think you could almost always do better than the OS allocator when writing servers. I'd agree its often not worth the effort. Unless you are writing lots of C. free() is such a pain. You can almost always write better, safer, faster memory allocators than ad hoc use of malloc() and free().