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

Re: [E-devel] Memory pool management



On Wednesday 22 March 2006 12:40, Carsten Haitzler wrote:
> [  8:35PM ~/t ] ./t ~/.e/e/applications/all/*
> 2.13070

> now with plain malloc as-is in cvs for eet:

> [  8:35PM ~/t ] ./t ~/.e/e/applications/all/*
> 2.04144

> it's actually a tiny bit faster. (and consistently so)... so - i'm
> wondering how u are really measuring speedups? the code i have will load

This is quite strange, I ran exactly the same code and I am seeing exactly 
the opposite (with and without valgrind) or I misunderstood something.

[ememoa]
cedric@futurama:~/ememoa$ ./bench ~e/.e/e/applications/all/*
0.22376
[plain malloc]
cedric@futurama:~/ememoa$ ./bench ~e/.e/e/applications/all/*
0.24617

ememoa with callgrind: 11.42089
ememoa with cachegrind: 13.34606

plain malloc with callgrind: 12.38373
plain malloc with cachegrind: 14.32375

> all the .eap's in my eap repo - which is a lot of eet work when bringing
> up a menu. sure there is a lot of other things here other than just pure
> eet code - but its closely representative of the core of the work.

In any case the winning is pretty small because only 'eet_open' and 
'eet_close' benefit from it. I chose first eet and specially 'eet_open' and 
'eet_close' because valgrind reported them as the second most important 
user of 'malloc'/'calloc'. They were also pretty easy to update without a 
big understanding of the code around them ('efn->data' is still allocated 
by 'malloc', as I don't see yet when it is being freed, neither who takes 
care of it).

	After updating 'eet_open'/'eet_close', we still have (for reference 
'eet_open' called malloc around 10000 times for the same scenario) :
       - 'eet_data_get_string': still the biggest user and by far (more than 
70000 calls)
       - 'evas_stringshare_add' (around 7000 calls to malloc)
       - '_eet_mem_alloc' (around 7000 calls also)
       - 'eet_read' (around 3000 calls)

Well, of course, evas_mempool_malloc is called a lot of time also (around 
25000 calls), but it seems to do a pretty good job. The only win I could 
see using ememoa for it, would be for mass murders of list's items (In the 
case of a pool per list) in 'evas_list_free'. But managing a memory pool 
per list will require a lot of change inside evas_list (Only internal I 
think).

All these functions need much more work and internal change if I want to 
show an interesting benchmark. Definitively, the most interesting one in my 
opinion is 'eet_data_get_string' and friends, and it will take some time 
before having some result. So what would be in your opinion a good target, 
or a good benchmark ?

	Cedric