Thanks for your speedy replies Gustavo and Cedric. Answers below. fre 2008-09-05 klockan 09:57 -0300 skrev Gustavo Sverzut Barbieri: > On Fri, Sep 5, 2008 at 8:55 AM, Cedric BAIL <[EMAIL PROTECTED]> wrote: > > 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 ? > > yep, that's amazingly huge, you should try to break it into multiple > edje and if possible into multiple layers, that can cut the searches a > lot. But it's not always possible...
I imagined edje was not designed for these amounts of data. I want to avoid multiple edje groups because I want to maintain a single Evas_Object. I might have to look at multiple groups but not if it can be avoided. Embryo would require a large redesign. We already have a lot of .edc code as you understand. Multiple "layers" -- is this the same thing as groups or have I missed something? > >> 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 use an embedded MIPS system. It does have a FPU. 128 MB available memory. I'm sorry, I don't think I'm allowed to go into details. <snip> Thanks for your Edje explanation, Cedric. I understand that maintaining dependency info and only updating related objects would save alot of calculations. I'm concerned to hear that some code cleanup is needed to carry out this optimization and that other small fixes are needed as well. This is hard to do for someone inexperienced with the full code base. > >> 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. Again, what is the status of EDJE_PROGRAM_CACHE? Is it safe to use after I fix the compilation problems? > >> 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.) Is surrounding my batch of edje calls with edje_freeze()/edje_thaw() a safe optimization? > >> 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 ? > > It's about pre_render (now calculate) callback for smart objects, > recalc is then delayed to render time: > > http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg18745.html Postponing recalc to the render time seems to be a good idea. I don't use smart objects, though. > >> 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. With the quick optimization to avoid _edje_part_recalc for invisible parts (explained later), opening a certain "page" in the application takes 1.8 sec, of which 70% is spent in _edje_match_fn. This is caused by 179 calls to edje_match_programs_exec. These are one-time events with the great EDJE_PROGRAM_CACHE, but the lags are most noticable. > > > >> - 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. This is an interesting idea. I might have a try at it. I'm sure embryo and grouping would help too but improving libraries is a better solution for us given the work already done. > > > >> - _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. Interesting! Is this different from the patch to pre_render for smart objects? Care to help me with a pointer to it? > > > > 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. I agree that graph dependency and caching for edje_part_recalc would be the best solution. But you indicate that this is not that easy to implement. In the meantime... this is my simple hack which avoids 90% of the calls to _edje_part_recalc: _edje_part_recalc(Edje *ed, Edje_Real_Part *ep, int flags) { unsigned char visible = ep->chosen_description->visible; if (!visible && !evas_object_visible_get(ep->object)) { return; } ... } The idea is that if the part was invisible and is still invisible at entry to recalc, no recalc is needed. This makes the dangerous assumption that no visible part depends on invisible parts. But if this is true, would the above code work as I imagine? Thanks for your kind assistance in solving this. I can spend a few days on improving Edje, but I need to know where my efforts are best spent. /Anders ------------------------------------------------------------------------- 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
