On 23.08.2006, at 14:46, Zoran Vasiljevic wrote:
Why wouldn't we making nsv interface public and use it for configuration store?
Eh... there is always yet-another gotcha! Because... the nature of the config interface is to allow case-insensitive or case sensitive lookups. Hence, sets are used in the current implementation. Peh! But, sets are SLOW. Because every time you need to get one "thing" out of the set, a linear lookup with a custom compare function is performed! But what if we expand the set to contain a small helping hash table? The hash table would cache the results of lookup so the very next time the same "thing" is looked up, the result would be delivered out of the cache? This may all be lazily computed so it would not bloat the memory... Hmhmhmhmhmhm... Perhaps this is more optimal solution? It would require very minor changes to the set implementation, would have a side effect of speeding up set operation (at least the lookup) generally and would allow for relatively fast lookup for a given "thing" (in this case config parameter). This will allow us to hold the global lock for duration of the entire operation on the set and implement read/write configuration with less work. The locking: we can employ the same locking mechanism as in nsv: compute a hash of the section name and map it to fixed number of buckets, each holding a lock. So effectively, we have numerous options: a. stay with sets but improve set lookup speed b. use nsv-code (would need to ditch case-insensitivity) c. use DOM based tree For a. and c. the locking contention can be minimized by splitting the entire "thing" into fixed number of buckets as in the nsv (the b.) option... Also, the complexity of implementation is a->b->c with a. being most simple. Now, what do you think about that? I hope I'm not overloading you with too much information! Cheers Zoran
