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
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. 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. 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. 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.) 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. 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? 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). - 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. - or if there are no wildcards in an .edj file, do a more efficient _edje_match_fn. - _edje_part_recalc only needs to update related objects - postpone _edje_recalc to cover multiple updates Other ideas how to make my project faster? Thank you, Anders Petersson ------------------------------------------------------------------------- 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
