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

Re: [E-devel] Memory pool management

On Wed, 22 Mar 2006 00:35:23 +0100 Cedric BAIL <cedric.bail@free.fr> babbled:

> 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.

have you tested ememoa heavily? i'm getting assert failures with this small test program i whipped up to see if what you say about this speeding up things like displaying menus (which loads a lot of edje objects - thus a lot of eet activity). the program is attached, and i get:

[ 11:44AM ~/t ] ./t ~/.e/e/applications/all/*
t: ememoa_mempool_fixed.c:281: compute_adress: Assertion `memory->object_size != 0' failed.
zsh: abort      ./t ~/.e/e/applications/all/*
[ 11:46AM ~/t ] gdb ./t                          
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) r ~/.e/e/applications/all/*
Starting program: /home/raster/t/t ~/.e/e/applications/all/*
[Thread debugging using libthread_db enabled]
[New Thread 46912543095344 (LWP 6600)]
t: ememoa_mempool_fixed.c:281: compute_adress: Assertion `memory->object_size != 0' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 46912543095344 (LWP 6600)]
0x00002aaaabd68de0 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x00002aaaabd68de0 in raise () from /lib/libc.so.6
#1  0x00002aaaabd6a290 in abort () from /lib/libc.so.6
#2  0x00002aaaabd61ffb in __assert_fail () from /lib/libc.so.6
#3  0x00002aaaacc10062 in compute_adress (memory=<value optimized out>, 
    slot=<value optimized out>, index=6) at ememoa_mempool_fixed.c:281
#4  0x00002aaaab741cf4 in eet_open (
    file=0x51bdb0 "/home/raster/.e/e/applications/all/A", 
    mode=EET_FILE_MODE_READ) at eet_lib.c:491
#5  0x00002aaaabc327b1 in _edje_cache_file_coll_open (
    file=0x51bdb0 "/home/raster/.e/e/applications/all/A", 
    coll=0x51bdf0 "icon", error_ret=0x51bb98, edc_ret=0x51bb58)
    at edje_cache.c:73
#6  0x00002aaaabc28998 in _edje_file_add (ed=0x51bb00) at edje_load.c:468
#7  0x00002aaaabc28f75 in edje_object_file_set (obj=0x51b910, 
    file=0x7fffffe3031c "/home/raster/.e/e/applications/all/A", 
    part=0x400dbc "icon") at edje_load.c:48
#8  0x0000000000400c25 in main ()
(gdb) fr 3
#3  0x00002aaaacc10062 in compute_adress (memory=<value optimized out>, 
    slot=<value optimized out>, index=6) at ememoa_mempool_fixed.c:281
281       assert(memory->object_size != 0);
(gdb) p memory
$1 = <value optimized out>

i need to do some more digging... but i smell a bug (it works fine with eet before being patched).

> Cedric
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd_______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
Tokyo, Japan (東京 日本)