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

Re: [E-devel] Memory pool management

Le Mardi 21 Mars 2006 22:21, Nathan Ingersoll a écrit :
> I think people are interested in this, but it's difficult to generate
> enthusiasm without some numbers to show why this is worthwhile. Some
> simple benchmarks to show how much improvement this has on common
> cases, like lists, would be helpful.

Well, it's not that easy to play fair on this. As I am manipulating a memory 
pool, I can dimension it to best suit the need of any benchmark. If you take 
a look at the prototype of the memory pool initialization prototype, you will 
see that I can dimension the memory pool as I want and unactivate mutex lock 
also if the application didn't require it.
	I have already used the same approch in anoser project that heavily used 
malloc (an assembler, http://savannah.nongnu.org/projects/aasm/) and the win 
was quite impressive compared to malloc (around 10 times faster). But this 
was a particular case, and will not really apply to enlightenment I believe.
	I will take a look tomorrow on how to provide some benchmark on this.

> Also, have you compared this against g_slice performance? They are
> using a magazine allocator algorithm and have shown a 50% improvement
> over standard malloc. The glib case also holds a warning when
> implementing your own allocator, their previous "fast" allocator was
> many times slower than standard malloc/free in most workloads. I think
> we should establish some good measurements before pushing something
> like this into common use.

Well it didn't really work in the same way. g_slice is working like malloc or 
free. It didn't have any information from the application to help him 
allocate objects used at the same time in the same memory area. The current 
design of ememoa provide a pool per objects class. So every time we ask a new 
object, we will be near the other objects of the same type. The allocation is 
certainly fast (no use of any system call most of the time, use of bitmask 
for searching empty slot), but more important all objects of the same type 
will have a lot of chance to be in the same memory area. It also provide the 
ability to do some garbage collection and to destroy an entire pool in one 
function call.

I hope it help to understand the behaviour of ememoa.