Re: [E-devel] Edje data speedup

[Carsten H. (T. R. <ra...@ra...>]

On Thu, 1 Mar 2007 00:23:17 -0600 "Nathan Ingersoll" <nin...@gm...>
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
> enl...@li...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...
裸好多
Tokyo, Japan (東京 日本)