4 ms·

Every once in a while I get involuntarily dragged into heated debates about whether reusing memory is better for performance than freeing it. I couldn't commen

Every once in a while I get involuntarily dragged into heated debates about whether reusing memory is better for performance than freeing it. I couldn't comment on all the instances the article talks about. But this way of asking the question seems to me to hide the problem. It seems simpler to say "what memory allocation algorithm should you use?" Which is to say, "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?". And so then you get into the massive number of technical considerations the article and others might raise. Memory allocation is a weird thing, it's an algorithm but it's often taken as a given in programming languages and discussions of algorithms.

bitcharmer 6y ago
Hi, author here. I'm not sure if I follow your argument. This article doesn't touch on allocators at all (ie. SLUB vs SLAB). It focuses solely on the cost of freeing memory which TLB-shootdowns are a notable part of. I even mention it at the beginning: > Regardless of the method by which your program acquired memory there are side effects of freeing/reclaiming it. This post focuses on the impact of so called TLB-shootdowns. Hope this helps.
- joe_the_user 6y ago
  As I understand things, allocating and freeing memory pretty much forms a single system. Especially, if I have a system where I "manually" allocate 10 meg for my use, never free it but use an internal method to mark the memory free or used, I will still have issues with caching and virtual memory based on my use of the memory. IE, reusing memory effectively creating a "roll your own" free and allocate functions. And in general, how contiguously you allocate memory plays a big part in whether freed memory can be easily discarded from the cache. If you get the heap to be exactly like a stack, then the cache shouldn't have problems. But I'll admit I'm not an expert and I could be missing something.
  - rocqua 6y ago
    This article isn't so much about free-ing, but about unmapping memory. It could well be that you have an allocator that decides not to un-map free-ed memory so that it can quickly be re-used later. That said, as per https://linux.die.net/man/3/malloc https://linux.die.net/man/3/malloc (and the article) the default implementation of free will (in some cases) unmap memory. It is this un-mapping of memory that causes other threads to be affected. Because those threads should get a seg-fault after the unmapping if they try to access that memory.
deleted 6y ago
[deleted]
userbinator 6y ago
Which is to say, "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?". The OS's memory allocator will likely be optimised for good all-round performance on some benchmark which may or may not be representative of your application.
- teknopaul 6y ago
  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().

bitcharmer 6y ago

Hi, author here. I'm not sure if I follow your argument. This article doesn't touch on allocators at all (ie. SLUB vs SLAB). It focuses solely on the cost of freeing memory which TLB-shootdowns are a notable part of. I even mention it at the beginning: > Regardless of the method by which your program acquired memory there are side effects of freeing/reclaiming it. This post focuses on the impact of so called TLB-shootdowns. Hope this helps.

joe_the_user 6y ago
As I understand things, allocating and freeing memory pretty much forms a single system. Especially, if I have a system where I "manually" allocate 10 meg for my use, never free it but use an internal method to mark the memory free or used, I will still have issues with caching and virtual memory based on my use of the memory. IE, reusing memory effectively creating a "roll your own" free and allocate functions. And in general, how contiguously you allocate memory plays a big part in whether freed memory can be easily discarded from the cache. If you get the heap to be exactly like a stack, then the cache shouldn't have problems. But I'll admit I'm not an expert and I could be missing something.
- rocqua 6y ago
  This article isn't so much about free-ing, but about unmapping memory. It could well be that you have an allocator that decides not to un-map free-ed memory so that it can quickly be re-used later. That said, as per https://linux.die.net/man/3/malloc https://linux.die.net/man/3/malloc (and the article) the default implementation of free will (in some cases) unmap memory. It is this un-mapping of memory that causes other threads to be affected. Because those threads should get a seg-fault after the unmapping if they try to access that memory.

deleted 6y ago

[deleted]

userbinator 6y ago

Which is to say, "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?". The OS's memory allocator will likely be optimised for good all-round performance on some benchmark which may or may not be representative of your application.

teknopaul 6y ago
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().