Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
alexey-panchenko at hotmail.ru wrote: > In the request_lock() function the whole map is scanned, very much > like a list. With large number of concurrent locks scan time will > increase linearly. Luckily the numbers don't get that large normally. > I suggest add additional "map<string, map<site_t,Lock*> >" keyed by > uppercased path. "map<site_t,Lock*>" will contain pointers to Lock > structures having the same uppercased path keyed by lockId. So, > instead of the whole map scan we will scan only the locks having the > same uppercased path, resulting in scan time O(log N). > > The disadvantage is that with suggested implementation we would not > notice leaking locks for some more time. ;-) It really doesn't make a lot of difference - the time taken to setup the map and copy the extra strings around offsets the advantages. The common case is maybe half a dozen locks active at a time, where the linear scan isn't significantly better than the lookup of a map (in the general case 90% of the loop is incrementing a pointer and comparing two integers. If you introduce a map it will always do string compares which is slower). Tony