On Jan 7, 2008 5:13 AM, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > On Jan 4, 2008 8:43 PM, Nathan Ingersoll <[EMAIL PROTECTED]> wrote: > > On Jan 4, 2008 4:02 PM, Cedric BAIL <[EMAIL PROTECTED]> wrote: > > > 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. > > > > Before getting into the details of your change ideas, could you > > explain the use case that you are profiling and the motivation behind > > it? For instance, are you seeing a slow load time when initially > > starting an application, or is this a case where various edje files > > are decoded over time, or accessing multiple data fields, etc?
Sorry Nathan, I did reply directly to you and not to the mailing, it was a mistake. So I am profiling the time needed by an edje object to become visible/active to the end user after the edje_object_file_set. I was only testing with some quite complex edje file with many swallowed object. I just did test with multiple edje file at the same time and the profile result look the same. > Nathan points are valid, of course, but I'm really interested in this > kind of stuff, because it's mostly "for free" if you can mmap it, also > it will help on high memory pressure situations, since these regions > would be file-based and can be evicted and reloaded when app is used > again (not a situation I'd like, but would help on embedded systems a > bit). Yes, it should help and reduce memory presure on embedded systems. > Cedric, something else related is trying to group these strings near, > so when they're loaded they'd be on the same memory page, this would > help disk seeks and the issue I pointed before. Any knowledge of this > area? Right now, string are repeated a lot in the eet file and they are at many different place. If you want to see this, just change the call to eet_data_write inside edje_cc_out.c to not compress data. So packing them together in one section and reducing them to only one occurence inside the eet file could be another improvement. But the way I see it (adding a new kind of section at the end of the eet file and refering to it) will break backward compatibility (eet file using this will not be loadable with previous libeet). It could solve some of the issue you are pointing. A side effect of this solution, we will not need to tell the application anything about the char* we are giving to it. Because all of them will be in a uncompressed section available as long as the eet file is referenced somewhere. This solution break eet file representation but not eet application. -- 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
