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]
[EMAIL PROTECTED]:~/ememoa$ ./bench ~e/.e/e/applications/all/*
0.22376
[plain malloc]
[EMAIL PROTECTED]:~/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
-------------------------------------------------------
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=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
