Creating a Memory Pool

Started by
12 comments, last by Animeplayer 12 years, 10 months ago
Hello Everyone, it's been a long time since I posted up something. I was wondering if anyone could provide a tutorial on Memory Pool, I have been having a hard time finding any type of resource to learn on how to create my own. I understand why you cannot use memory dynamically allocated commands in the C program i.e.(new and malloc) because they are not as efficient as creating your very own. So can anyone provide me with some materials or tutorial as to how to create my own?
Advertisement

I understand why you cannot use memory dynamically allocated commands in the C program i.e.(new and malloc) because they are not as efficient as creating your very own.
[/quote]
Have you determined where you need to pool memory? This is an optimisation, and thus must be carefully and selectively applied. If you try to pool everything you end up with a general memory allocator, and likely not particularly faster than the runtime's version.

What are your requirements? Memory pools work best when they are used with a fixed size, this is the easiest one to create and manage, and avoids fragmentation.

So can anyone provide me with some materials or tutorial as to how to create my own?
[/quote]
I typed "Memory Pool Tutorial" into Google and get lots of results. I don't have time to screen them, but can you address why you found them deficient?

I understand why you cannot use memory dynamically allocated commands in the C program i.e.(new and malloc) because they are not as efficient as creating your very own.

Certainly you can use malloc (in C and C++) and new (in C++) in your programs. In fact, that's probably exactly what you'll want to do unless you have a specific need for a custom solution. (Even then, you might look into existing solutions, such as boost::pool if you're using C++, rather than implementing something from scratch.)

[Edit: Fixed error in post.]
A not very efficient, but simple pool:[source lang=cpp]class MyPool
{
private:
MyObject objects[9000];
bool isUsed[9000];
public:
MyPool()
{
for(int i=0; i<9000; ++i)
isUsed = false;
}
MyObject* Alloc()
{
MyObject* result = NULL;
for(int i=0; i<9000; ++i)
{
if(isUsed == false)
{
isUsed = true;
result = &MyObject;
}
}
return result;
}
void Free(MyObject* ptr)
{
assert( ptr >= objects && ptr < objects+9000 );
int index = (int)(ptr - objects);
assert( isUsed[index] == true );
isUsed = false;
}
};[/source]This kind of thing was everywhere in old C game code-bases... What's made you decide you need one?


Have you determined where you need to pool memory? This is an optimisation, and thus must be carefully and selectively applied. If you try to pool everything you end up with a general memory allocator, and likely not particularly faster than the runtime's version.

What are your requirements? Memory pools work best when they are used with a fixed size, this is the easiest one to create and manage, and avoids fragmentation.

Alright, let's say I want to use 65536 in my memory pool and allocating from sizes of 2 bytes to 16k bytes.


I typed "Memory Pool Tutorial" into Google and get lots of results. I don't have time to screen them, but can you address why you found them deficient?
[/quote]
The ones I came up with was more explanation about memory pool but could not find any comparison of codes between creating your own without using Dynamic allocated commands in C that is given.
[/quote]

This kind of thing was everywhere in old C game code-bases... What's made you decide you need one?

I was asked this question to code my own pool, I did not know how to approach it since my college didn't teach me this. So I knew that this is a new skill I must learn.
As far as I am concern, both malloc and new create fragmented memory on most OS and are not particulary optimal in that sense. That doesn't mean you need to replace them, means you need to be aware on this fact.
malloc() and new aren't OS specific, they're compiler and standard library implementation specific. For that matter, the behavior of those can be dependent on things like environment variables and whether or not the the program is launched from a debugger. For instance, even in release mode, if you launch an MSVC project from the IDE it'll use an allocator that has more bookkeeping information, but some Borland compilers on the same OS will already do memory pooling for small block allocations.

I did not know how to approach it since my college didn't teach me this.
[/quote]
College will not teach you everything. As I mentioned earlier, I get lots of results when searching Google for this topic. If you're having tourble, can you ask a more specific question. E.g. "I was reading here but I don't understand concept X or code fragment Y."
You are correct compilers use their own tricks to try to have more efficient dynamic memory pooling, yet in the end it has to rely on a sys_call. It was incorrect from me to name it OS dependant.

This topic is closed to new replies.

Advertisement