On Jan 7, 2008 10:43 AM, Cedric BAIL <[EMAIL PROTECTED]> wrote: > 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.
I'm not sure others will like, but I do like this idea, and given raster's word that "after E is marked stable, it will have to be stable, so break things before it's released", I really think we should fix this now (and break compat) rather than staying with this for some years more. -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ------------------------------------------------------------------------- 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
