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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
