Of course the libc allocator is slow, it's designed as a one-size-fits-all solution that's poorly tuned for most workloads and often doesn't get substantially updated for decades. By writing your own, you aren't avoiding an allocator, you're just avoiding the libc implementation of an allocator.
(In fact, most libcs let you just redefine the malloc(), free(), and realloc() functions to point to your own allocator instead of the default one, so you don't have to rewrite all the functions calling them. E.g., the mimalloc allocator [0] can be configured as a drop-in replacement for the libc allocator.)
I guess I'm confused at this chain of responses, then. As I'm doing what you are already suggesting.
Re-reading your comment, about the "not really freeing anything" -- I beg to differ, as when you do a real free(), it frees up memory for any program to use. As I already mentioned one of the benefits is once you have control of who can use that memory and aren't risking it not being available - disregarding some program that constantly grows in memory.
Your description reveals a complete lack of understanding, and pointing out someone's lack of understanding is not being pedantic. Your choice of wording—"real free()" and "any program"—misrepresents the inherent complexity of implementing an allocator and does a disservice to both those less experienced and to the discussion in this thread.
You're assuming a platform. There are not a great number of guarantees when it comes to free:
The free subroutine deallocates a block of memory previously allocated by the malloc subsystem. Undefined results occur if the Pointer parameter is not an address that has previously been allocated by the malloc subsystem, or if the Pointer parameter has already been deallocated. If the Pointer parameter is NULL, no action occurs.
All that is guaranteed, is a deallocation. Not how and when that memory will become available again.
Your "more detailed" understanding will break, and will cause headaches, on platforms ypu're not used to.
(In fact, most libcs let you just redefine the malloc(), free(), and realloc() functions to point to your own allocator instead of the default one, so you don't have to rewrite all the functions calling them. E.g., the mimalloc allocator [0] can be configured as a drop-in replacement for the libc allocator.)
[0] https://github.com/microsoft/mimalloc