On Fri, 05 Sep 2008 13:25:33 +0200 Anders Petersson <[EMAIL PROTECTED]> babbled:
> Hello, > I am working on a project that makes use of edje/evas with large .edj > files. We have problems with performance. Here is an example of an .edj > file we use: > 4300 programs > 2126 parts > 7940 "after" clauses for a program to invoke another programs OUCH OUCH OUCH! edje was not designed for this! all in 1 edje object? god damn!!! did you write something to generate the .edc? > At any one time, only a small number of these parts are visible. > For performance and simplicity, we limit the number of Evas_Objects to > one, so all parts are contained in the same edje group. hmm - this will be a misnoma. every part will exist as an object - inside the edje object it has sub-objects. you will be suffering from a high object count for evas to deal with as well as edje really being pushed its intended use. > Even a simple operation with modest graphics updates by 10 > edje_object_part_text_set and 10-20 edje_object_signal_emit took > hundreds of ms or more. not surprising! i'm amazed it isnt worse :( > I reduced the running time of edje_match_programs_exec by turning on > EDJE_PROGRAM_CACHE. This required me to fix some simple compilation > errors. Is EDJE_PROGRAM_CACHE ever used and considered stable enough? > But after all other optimizations, _edje_match_fn again accounts for 50% > of used CPU time. because the program matchintg is a linear walk - of all programs, per signal. the cache is something i played with long ago when someone wrote a script to gnerate a .edc to do the "matrix" effect. he really just pushed edje beyond what it was intended. i played with the cache - but it was a memory vs speed tradeoff. the cache of course really added a fairly chunky memory footprint. whats really was being done is the simple "programs" which are intended as simple linking of event -> reaction, was being used as a pseudo programming-language. that is when i moved to put embryo in - to put a "programming language" in to do "programming language stuff". this solved the tradeoff problem by not needing it anymore. so i disabled it and have ignored it ever since. this was years ago... > As a result of the user pressing a button, I might want to do ten > edje_object_part_text_set and send some signals to update the visible > state. This causes a large number of _edje_recalc that takes a lot of > time (ex: 58 calls in a row taking 10-20 ms each). > Is there a drawback to calling edje_freeze()/edje_thaw() around all my > methods that reacts to user input? (We don't handle keypresses through > evas, so we only want to update the GUI state.) there shouln't be a problem here. it simply suspends the signal/event system and edje ignores anything that would generate signals/events (like moves, resizes etc.). its mostly intended for when doing setup or shutdown or en-masse reconfiguration of many objects. > Doing edje_freeze()/edje_thaw() around our ten edje_object_part_text_set > calls improves the situation, but not nearly good enough. > In some situations we have 20000 invocations of _edje_part_recalc for > some simple graphics operations. Once EDJE_PROGRAM_CACHE is enabled, > this is where the application spends most of its time. corect! edje will be conservative and walk the part list as it expects it to be fairly small (5, 10, 20 - maybe 50 or so at most) and so it wouldn't help a huge amount to have dependencies. it does mark the parts as dirty so it can skip a calc - but the walk still happens. > What is your opinion of how worthwile it is to do different > optimizations of Edje for someone like me, with a few days of experience > with the source? ummm... gez. well - i'll get back to this below. > Here are some possibilities: > - Starting the executing of a program internally with signal > "program,start" could refer to the program struct directly instead of > the textual program name. (This would avoid many of the > edje_match_programs_exec calls). this would help- you can attach the "source" pointer, not just use its name. > - Isn't it possible to make a faster implementation of > edje_match_programs_exec/_edje_match_fn? Especially our long 'source' > names takes time to resolve. gee - possible - but as above.. edje wasn't intended for this level of "abuse" :) > - or if there are no wildcards in an .edj file, do a more efficient > _edje_match_fn. yes. in fact since we use string tokens - the pointer will be the same so u can reduce it to a pointer compare - but i think edje already does this assuming if the ptrs are the same, the string is. but only if the string comes from the same pool. in this case the mmap()ed string dictionary in the .edj file. > - _edje_part_recalc only needs to update related objects this is possible - but will make life complicated/ > - postpone _edje_recalc to cover multiple updates good and bad. deferring (queuing this) is good - but it may need to be done if u need to query current state. edje does this for messages (which covers signals too) but not calcs > Other ideas how to make my project faster? well - really. split your thing up. making it 1 big edje object is going to cause problems. and continue to. i think i know what you've done - you've generated the WHOLE ui in 1 .edj. maybe a set-top-box which of course has a limited # of "screens" thus why only a small subset are visible at any one time. really - this si where code was meant to take over- split the ui into things that come and go (screen elements) repeat items (if you have lists of items have 1 edje object per list item), and then overlay/underlay objects or things always there (eg a status display in the corner etc.). he code deals with navigating and the overall logic - edje deals with the fiddly "but i want that icon aligned 5 pixels closer to the edge and green with this border, and make it pulsate when selected" stuff... to improve things this is where i have looked at making "script only" objects - they dont have parts and layout - only script and callbacks - they can load/delete or create edje and evas objects (only edje objects from the same file though for sandboxing), but for this... embryo may be pushing it - we need to develop lots of layers that something like lua already provides. no allocation within the embryo vm heap for example - no pointer <-> embryo variable (handle) mapping system etc. etc. but this isn't a small project. other things that might help is not crating edje objects for non-visible parts - and deleting them when they go invisible.. but now show/hide becomes a lot more expensive. other than that the way you are using edje would improve with compartmentalising - ie the elements within one "Screen" are isolated signal-wise and program-wise from others as they really don't have anything to do with eachother. (this is the bit where we normally would expect "Code" to split things and thus compartmentalise by having lots of separate edje objects). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
