lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Sep 11, 2008, at 4:26 AM, David Jones wrote:

If you're suffering performance problems that you believe are due to memory allocation then plug in another memory allocator. Such as dlmalloc. Do NOT write your own.

If you're still suffering performance problems and you are absolutely sure that it is the memory allocator, then better start reading some papers. Start here: bib/ and here: .

If your summary of Boosts' memory pool template class is correct, then they had better start reading some papers too.
No performance problems at all. Just looking to see if there's another use for what I plan on putting together.

Thinking over what I summarized as what happened, it turns out I got it mostly wrong... In trying to digest what needed to be done, I only thought out the case of data-size < ptr. A union will certainly not work here... now I see why they did LCM.... and why the ugly case looks like it does.

Target usage-- Note: Pools allocated for single data-types
Certain data items are expected to either be allocated/deallocated frequently (esp if no arrays of objects needed) or would like fast deterministic time OR it's highly beneficial that their memory can be dumped (optionally [if 1 element only] destructed w/ a function)

You can also get some other bonuses for normal use, such as locality/ etc.

Basic assumptions made:
* Arrays may not have padding... otherwise most assumptions will not work (sizeof array / sizeof element != num elements) * Block memory allocator will allocate blocks properly aligned such that the returned ptr will be aligned for (at least) a single element of any data-type <= the size requested.. ex: alloc(128) good enough for double, float, etc since they're all < 128... not necessarily good enough for a 200-byte object.

Ascii-drawing of an ugly case
	sizeof(T)         == 5
	sizeof(void*)     == 3
	sizeof(size_type) == 1

LCM(3,1)   == 3
LCM(5,3,1) == 15

Individual unit-chunk....
size  void* T
1     3    |5
1     (12) | -- (10) left over
1          |
1     3    |
1          |
1          |
1     3    |
1          |
1          |

In the normal case... such as a struct { void* ptr, int x, char z }
The compiler will pad it out such that in an array of them, the accesses are aligned...
Ex: AMD64
	sizeof(that T) == 16
	sizeof(void*)  == 8
	sizeof(size_t) == 8
LCM = 16 -- perfect!