Re: [E-devel] Epsilon [PATCHES]
The patches are very small and their names are pretty self-explanatory :-) 0001-Fixed-w-h-unnoticed-miss-exchange.patch: Fixed w - h unnoticed miss-exchange, when calculating thumbnail geometry 0002-Fix-alignment.patch: Fix alignment 0003-segfault_check_epsilon_cb_server_data.patch: Added IF in epsilon_thumb.c's epsilon_cb_server_data to avoid segfault If you have time, please take a look and if you have questions I'm sure that Leo will answer them. Would be nice to get these patches upstream. Cheers, Kenneth On Thu, May 8, 2008 at 5:53 PM, Christopher Michael [EMAIL PROTECTED] wrote: Leo Sobral Cunha wrote: hi guys, attached are some patches for epsilon, mostly small bugfixes. any comments? BR, Just FYI, but in the future please add a short description somewhere in your email about what your patches address. mostly small bugfixes is just a bit too generic :) What bugs? It saves the developers some time. Thanks dh - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-05-09 07:09:10 -0700
Build log for Enlightenment DR 0.17 on 2008-05-09 07:09:10 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log evolve http://download.enlightenment.org/tests/logs/evolve.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Carsten Haitzler (The Rasterman) schrieb: after. i've run the tests myself now. i'll add some stats. e17 maintains about 3000-4000 unique strings in evas_stringshare. in my tests. i also checked on number of adds, dels and lookups in evas_stringshare usage. about 6.48% of calls are for adds of a unique string. 5.12% are for deletes of a string. 88.41% are accesses (an add or a del of an existing string where the operation does not free or allocate any memory but just refcounts up or down). now based on this, the existing stringshare vs. string_instance means, that if you account for the relative usage of add, del and access paths, string_instance gets overall faster once you have about 3200 or so strings. so e17 is about at the cusp point. it's also one of the heavier users i imagine. i simply changed hash bucket size to be 1024 items instead of 256 and that makes the crossover point at about 7200 strings items - well beyond normal usage of e17 anyway. adds and delets are still significantly faster (string instance takes 1.8 and 1.4 times the time respectively compared to stringshare) even at 10,000 strings. with the 1024 buckets for stringshare of course. but string_instance takes 0.8 times the time for lookups. overall it's a close race. i'll try improve stringshare a little and see what i get, but beyond making it have dynamic bucket sizes (like ecore_hash) it isn't likely to go far. a dynamic bucket size will mean it will scale very high (question: do we need it to go that high?) but the idea of having to re-do the bucket array at certain points is a little uncomfortable (so u go from 3000 to 3001 and the system has to spend extra cycles re-packing all hash items in a new bucket set thats bigger). yes - this is nicer in terms of base mem usage of course. so the thing here is to figure out how to get the best thing we can for the least cost. i do know stringshare has a 1 alloc per unique string overhead. thats about as small as it gets (also either 8 or 12 bytes (32 or 64bit) per unique string for refcount and pointer). The (only) one alloc is most probably the reason why has better results for adds and removes then the ecore counter-parts. It's probably possible somehow to improve the situation for ecore_hash, but it'd make the code more of ecore_hash to alloc only one piece of memory per item. I think it isn't worth it, because i don't see a general usage for such a feature. now... more interestingly - i now started looking at the test. it is very artificial. Yes, i know. I start to read the two implementations and saw the difference. And i wondered if how they affect the performance. How much is the overhead of the two allocations? Where will evas start to suck, because of the static bucket count. So i've written the test case to get a feeling for it. I know it is artificial, but I think it is still interesting, even if it doesn't represent a normal usage. at most 2 copies of a string, so n repeated adds, and all short strings. not very representative of common usage. in common usage i have seen some strings with refcounts of 200. in fact the del wont work with stringshare. on del u need to supply the actual string pointer - not the snprintf'd buffer. so nothing gets found and deleted. ie its meant to work with: char *s; s = evas_stringshare_add(string); ... evas_stringshare_del(s); ie - the same return from stringshare. evas_stringshare_del(string) will not work. ... so as such you need a test that is more representative of actual usage. so that's just what i did. i literally logged all stringshare add's, dels etc. in such a way it'd produce correct code from a session of e17 i fiddled with for about 5 minutes doing stuff. you'll forgive me for not including the code as the .c file generated is 11m (239,000 lines of c) that i included into the compare.c infra to test both ecore and evas code and just time it doing exactly what e does. i also included nops where functions are called, but do nothing so we can remove the simple test harness and function call overhead and compare just core. as it was a little too fast i make it run 1000 loops of what e actually does one after the other (yes it'll be bad as it doesn't start with a clean slate but better than nothing). result for 1000 iterations one after the other: evas: 20.691495 ecore: 30.510302 nops: 3.444793 real factor: 1.57 so really 20.69 - 3.44 vs 30.51 - 3.44 - i.e 17.25 vs 27.07 (evas being the lower). yes - this means a lot of things will get high refcounts as things get re-added a lot and then not removed, so the raw results of only 1 iteration: evas: 0.031672 ecore: 0.045482 nops: 0.004831 real factor: 1.51 not as accurate as the times are so small, but the same order of magnitude as above. so as such... if we are doing benchmarks to know which implementation to use to find the one with best results - at least for the
Re: [E-devel] Epsilon [PATCHES]
On Thu, May 8, 2008 at 2:46 PM, Leo Sobral Cunha [EMAIL PROTECTED] wrote: hi guys, attached are some patches for epsilon, mostly small bugfixes. any comments? The first patch had some indentation problems, I fixed and committed them all. Thanks! -- Gustavo Sverzut Barbieri http://profusion.mobi Embedded Systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
