[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
I hope it help to understand the behaviour of ememoa.