Hi, I am looking for a way to improve edje file load time. Right now a large amount of time is logically lost in _eet_data_descriptor_decode. So looking at its profile, most of the time is lost in manipulating string.
It took me sometime to understand why we need to strdup all EET_T_STRING before returning them. In fact, it's only needed when the Eet_File_Node is compressed, in other case it's not needed. We could just return a pointer to the string and it will live for as long as someone reference the eet file. So inside eet itself its not needed to malloc/free all EET_T_STRING (as the data is valid during all the runtime of _eet_data_descriptor_decode). Outside of Eet, we have two possibilities : - we don't change anything (just duplicating all EET_T_STRING in str_alloc like we do now) - we can pass a flag to let the application know that the pointer will live as long as the Eet file referenced. The second solution will break all application using Eet_Data_Descriptor_Class as we will need to change str_alloc prototype. I know that Edje and E are using Eet directly, perhaps Rage also. But the first change could be minimal, just a small wrapper that ignore the flag and always dup, will do the job. For Edje, most of EET_T_STRING are in "edje_file" Eet_File_Node and guess what it's compressed. So it will require modification to edje_cc_out.c to choose if we want to compress this Eet_File_Node or not (could depend on a command line parameter for example). I did a quick implementation of this idea, and load time did improve (around 10% global speed improvement in my test case). eet_data_descriptor_decode doesn't use as much time in load process as before (from 30% of total load time to 15%). The draw back is edje file size increase, as an example for Enlightenment theme it will increase from 2.5M to 2.6M. As making a clean patch for this will take time, I would like to have comments and feed back on this idea before. -- Cedric BAIL ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
