On Thu, 1 Mar 2007 00:23:17 -0600 "Nathan Ingersoll" <[EMAIL PROTECTED]> babbled:
cool! nice work on the profiling. anyway - you hit a usage case i didn't expect/intend for the edje file data - i expected it to be used rarely so it wouldn't be a bottlneck. hashes are fairly big as they need to allocate space for at least N bucket points to start with, so if you only have a few items, i decided no hash was the way to go - given the above assumption, it saved memory and would be ok. 1 hash per file though isn't too bad - and i think that'd be acceptable, but you can also have object data (done the same way) and then per object you'd need a hash (well per source object - each instance cah share the source config for the group object). no need to break the format here - just populate the hash on load from the list (then even free up the list and empty it). :) > Doing some profiling, I noticed that I was seeing a fair amount of > overhead (19.9% of the test apps completion time) coming from strcmp, > and in particular from calls to edje_file_data_get. This isn't > completely unexpected as EWL uses data keys in the edje to map widgets > to edje collections, but it had me wondering why there were so many > comparisons relative to other hot paths in the code. > > The problem became clear when I saw how data lookups were being done, > a linear scan of a list doing strcmp against each key in the list > until a match was found. With each search being O(n), this could add > up quickly. Since we are using key/value pairs for the data > association, a hash seemed more appropriate. > > To test this without breaking the file format, I added a cache to the > edje file struct and populated it immediately after reading the file > by moving data out of the list and into the hash. Using the new hash I > re-ran my test and saw an improvement of 18.5%, and basically > eliminating almost the entire time spent in edje_file_data_get. > > While I don't expect to see a huge improvement, this would be more > efficient using a hash directly in the eet. The downside would be that > compatibility would be broken for existing edje's. > > So that finally brings me to my questions: what is the current policy > on breaking edje compatibility? and does anyone have an objection to > moving the data storage to be a hash rather than a list? > > Thanks, > Nathan > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
