On Wed, 22 Mar 2006 16:53:07 +0100 Cedric <[EMAIL PROTECTED]> babbled:
> 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
i actually think the speed differences are going to be much of a muchness -
depending on cpu arch (this is an amd64 cpu with everything in 64bit), how your
libc is compiled, etc. etc. etc. - i am not sure we can show consistent wins.
if its faster on one box, and slower on another - it likely is better to do
"nothingg" until u win on at least 1 arch/cpu and don't loose on others.
> 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).
it is not freed by eet. it's freed by the app that calls eet - so by definition
you HAVE to use malloc with it as it is expected to use free() to free 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 ?
hmm - well you need to possibly open e17's default theme (default.edj) and then
just choose lets say 10 keys from it to load - load them, then close. do that
in a loop (choose the keys at random). this should negate any caches etc. in
between other than the kernel's disk/buffer cache (which you want fully primed
to remove disk IO from the equation).
in some ways i think some eet "rewrok" would speed things up more.
1. actually mmap() instead of fopen() and actually don't malloc data for things
like the strings in the key table if we can return a DIRECT POINTER to it from
the mmaped segment.
2. add a eet_read_direct() that reads the data and returns a pointer to the
mmap()ed data segment (if it is not compressed - if it's compressed you cannot
use this call). this will avoid an alloc and memcopy for several useful cases
like image loads.
i think you'll get much more mileage from these than malloc pool work - as it's
already dubious if such pools help (one system they speed up, another they slow
down). the above will make eet much more tied to unix and less portable - BUT
that's fine by me. we aren't about supporting win32 :) anyway - the mmaps will
avoid a whole lot of mallocs :)
> 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
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)
-------------------------------------------------------
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
