Skip to content

Commit d6d6bb2

Browse files
committed
Update README.md
1 parent 54e8b19 commit d6d6bb2

File tree

1 file changed

+6
-1
lines changed

1 file changed

+6
-1
lines changed

README.md

Lines changed: 6 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,19 +8,22 @@ This library uses variadic templates for perfect argument forwarding and some ot
88
What is a Memory Pool
99
-----------------------------------------
1010
You would normally use `malloc` or `new` for dynamic memory management in C/C++. These functions are rather slow and have some memory overhead attached to them. This is fine if you make a few calls and ask for large chunks of memory, but if you need to store many small objects, the time and memory overhead may be unacceptable for high performance programs. This is where a memory pool comes in.
11-
A memory pool allocates memory in big chunks and splits the memory into smaller pieces. Every time you request memory, one of these small chunks is returned instead making a call to the OS or the heap allocator. You can only use a memory pool if you know the size of the objects beforehand, but if you do, a memory pool has quite a few advantages:
11+
A memory pool allocates memory in big chunks and splits the memory into smaller pieces. Every time you request memory, one of these small chunks is returned instead making a call to the OS or the heap allocator. You can only use a memory pool if you know the size of the objects beforehand, but if you do, a memory pool has a lot of advantages:
12+
1213
* It is substantially faster than `malloc` or `new`
1314
* There is almost no memory overhead since the size of each object is known beforehand (i.e. no need to store allocation metadata)
1415
* There is little to no memory fragmentation
1516
* You do not need to free object one by one. The allocator will free all the memory it allocated once its destructor is called. Note that this only works if the objects have a default destructor.
1617

1718
A memory pool has just a few disadvantages:
19+
1820
* Objects have a fixed size which must be known beforehand. This is usually not a problem and mostly the case if you need to allocate them in a bunch
1921
* You may need to fine tune them for your specific application. This is made very easy with the use of template classes.
2022

2123
C++ Compliance
2224
-------------------------
2325
MemoryPool is mostly compliant with the C++ Standard Library allocators. This means you can use it with `allocator_traits` ([see here] (http://www.cplusplus.com/reference/memory/allocator_traits/)) or just like you would use the `std::allocator` ([see here] (http://www.cplusplus.com/reference/memory/allocator/)). There are some differences though:
26+
2427
* MemorPool **cannot** allocate multiple objects with a single call to `allocate` and will simply ignore the count value you pass to the allocate/deallocate function. Fixing this is not too hard, but it would deteriorate performance and create memory fragmentation.
2528
* This is **NOT** thread safe. You should create a different instance for each thread (suggested) or find some way of scheduling queries to the allocator.
2629

@@ -84,7 +87,9 @@ For objects that contain several pointers, the default size of 4096 bytes should
8487
About the Code
8588
-------------------------
8689
Here are a few important points that you should know about the code:
90+
8791
* This code handles alignment for the objects automatically, which is necessary for high performance memory access and may even be required on certain processors. However, it assumes the memory returned by `operator new` is "aligned enough" to store a pointer. This assumption was not necessary, but since it is reasonable enough, I decided to remove two lines of code. I am not sure if this is required by the standard, but all C code using `malloc` would crash (or run extremely slowly) if this was not the case.
92+
8893
* The allocator does not free any memory until it is destructed (though it does re-use the memory that you deallocate). This is fine if you only allocate objects, or if you deallocate and re-allocate objects equally often. This is only a problem if you have peaks of high memory usage and you expect the memory to be freed during low memory periods. This was a design choice to substantially improve the performance, and under most cases you do not need to worry about this. It is good to keep this mind for projects that require special handling of the memory though.
8994

9095
License

0 commit comments

Comments
 (0)