Your commit c0d6cbab97a1fac072aa1a7101165d9db25903a7 (eet - dictionary - use rwlocks instead of spinlocks - better contention) has a performance regression both on Linux Desktop (Ubuntu) as well as Tizen . eet_data_read() takes double the time because of change from spinlock to rwlock. I have some vtune profiling data i can share with you if you need . But the simple test will be put ecore_time_get() to see how much time that function takes. Is there any case where we are reading from the eet file from multiple thread simultaneously (in Efl) . As eet_data_read() will call eet_dictionary functions lot of time (depending on how big data structure we are reading) the number of locks and unlocks are really huge which takes 60-70 % of total read time .. instead of that if we take the lock from dictionary at start and then do the read and release the lock that will improve the performance a lot (of course it will make the eet_data_read() function sequential). atleast the read time is predictable .
- I am still trying to figure out why eet_dictionary_get() API is public (this is a internal data structure of eet which is there to reduce the memory by using same string(if i am correct) by making it public we are forced to put locks on every api get/set which affect the base use case (reading from eet data).
Please let me know your thoughts on this.
Data: By changing the locks back to spinlock the startup time improved by 60ms . and removing the locks all together improved another 20ms.