On Fri, Sep 5, 2008 at 1:25 PM, Anders Petersson <[EMAIL PROTECTED]> wrote: > 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. That's really huge. Did you consider using "embryo" script for it ? Or are their any limitation that prevent you from using it. Another thing, did you use edje "group" part ? > 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. Can you describe a bit your target platform ? RAM, Mhz, CPU type, does it have FPU ? This kind of information, just to have a better idea of your constrain. > 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. Some time ago, Gustavo did provide a set of patch for doing recalc only when required. Can you try it ? > 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. This piece of code as already received some good optimisation, their are always space for improvements, but I don't think you will win the amount of performance you need. > - or if there are no wildcards in an .edj file, do a more efficient > _edje_match_fn. A possible solution could be in that case to build a binary tree, and use it for the lookup. You will have around 13 strcmp in your case to find any program if you don't use '*'. I may be wrong, but I think using "embryo" script and "group" part, will reduce so much the number of entry in the program table to make it usable. > - _edje_part_recalc only needs to update related objects > - postpone _edje_recalc to cover multiple updates Patch for evas and edje to do recalc as late as possible is sitting somewhere on the ML archive. But more could be done to improve edje_part_recalc. We need to clean the code, and build some graph dependency so that only the needed part will be recalculated and not the entire edje object. Caching the previous result would also help in the case of animation where we calculate both start and destination for each step of the animation. I don't really know what would be the best implementation for this improvement, but edje is really not as fast as it could be. Hope it help. PS: Between, regarding embryo, we are about to switch to lua in a near future, so be aware of futur breakage. -- Cedric BAIL ------------------------------------------------------------------------- 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
