1

The idea is writing a memory manager that allocates a bunch of memory at a time to minimize malloc and free calls, i've tried writing this by my self two times but both times i ran into the problem of defragmenting memory.

You could just check if a block is empty every so often, and if it is empty delete it. But let's say your blocks are 100 bytes each, first you allocate 20 bytes of memory, this will create a new 100 byte block because no blocks exist yet, then you allocate 80 bytes and this fills the first block, then you allocate another 20 bytes and this will create another new block because this first block is full, then you free the second allocation (80 bytes) and that leaves you with two blocks of which only the first 20 bytes are used, this means you have 100 bytes allocated that could be freed by moving the 20 bytes from the second block into the first block and deleting the second block.

These are the problems i ran into:

  1. you can't move the memory around because this means all pointers to that memory will have to be updated, and for that to happen you need to know their addresses, which you don't;
  2. 100 bytes is a very small block size, what if i want to store a very low-res (64,64) ARGB image in memory? This will use 16KB of memory and moving all of that might be even slower than just not writing a memory manager at all.

Is it even worth it writing a custom memory manager after all that?

DutChen18
  • 1,133
  • 1
  • 7
  • 24
  • Have a look at buddy systems - https://en.wikipedia.org/wiki/Buddy_memory_allocation –  May 02 '17 at 17:10
  • 3
    Are you having an *actual* performance problem you need to solve? If not, then I'd say this is premature optimization. – Jesper Juhl May 02 '17 at 17:12
  • 5
    Most malloc/free implementations in common use have been written by talented and experienced programmers with in-depth knowledge of the problem domain, and have then been polished over time in light of any deficiencies discovered in actual use. That doesn't mean that they are the best possible implementations, but it suggests that you are unlikely to do better on a first attempt. – rici May 02 '17 at 17:16
  • Although the question was a little different, I think you may find this answer useful: http://stackoverflow.com/a/7368535/1386054 – Adrian McCarthy May 02 '17 at 17:29
  • 2
    JesperJuhl Since i write code for fun, everything i do is premature since i'll probably never be using it in practice. NeilButterworth i don't see how this solves the fragmentation problem, allocating 3 blocks and deleting the second one still leaves unused memory. rici When 2 processes call malloc at the same time one will need to wait for the other to finish, writing my own manager for single-threaded applications might be faster, i don't know for sure since i haven't managed to write one yet. – DutChen18 May 02 '17 at 17:34

1 Answers1

1

Is it even worth it writing a custom memory manager after all that?

This is asking for an opinion, but I'll try to give a factual answer.

The memory allocators that come with most operating systems and language support libraries are generally very high quality and are designed to address the types of problems you encountered (fragmentation and performance) as well as others. They are about as good as general purpose memory allocators can be.

You can do (a little) better than the provided memory allocator if your application has a particular allocation pattern that can be exploited. That's rare, but you can generally take advantage of it by making something substantially simpler than a general purpose memory manager.

you can't move the memory around

True. Most modern systems don't even try to move memory around--they try to avoid fragmentation to begin with (typically by clustering similarly sized allocations).

Old systems (ones without virtual memory managers) sometimes used memory managers that had an extra layer of indirection. Instead of returning a pointer to the allocated memory, the allocator would return an "handle", which could be as simple as an index into a table maintained by the memory manager. When the user wanted to actually access the memory, they would "lock" it. The memory manager was free to move around memory that wasn't locked (e.g., to eliminate fragmentation) because the handles gave an extra level of indirection.

what if i want to store a very low-res (64,64) ARGB image

Most memory managers provide a range of sizes so a large allocation wouldn't be split across n smaller blocks. Most will punt very large allocations to the system allocator, which, on a virtual memory operating system, can generally solve the problem unless the process address space is overly fragmented.

Adrian McCarthy
  • 45,555
  • 16
  • 123
  • 175