Berin Loritsch wrote: > Stefano Mazzocchi wrote: > >> Berin Loritsch wrote: >> >> >>> The question remains about the ECM itself yet. I haven't had time to >>> write >>> the profiling tests yet. >>> >> >> I fully trust your judgement on this. > > > > :) > > I found out that the ECM implementation has been changed, and the > hashmaps backing > the ECM are now Container.synchronizedMap() wrapped. :( > > When I took off the synchronization, the time spent for 50,000 requests > with 20 > concurrent threads went from ~80,000ms to ~9,000ms. However this is not a > threadsafe solution--I will add back in the external locking mechanism > (the ReadWriteLock) > and make this work safely and a bit better.
Ok, The current version of ExcaliburComponentManager/ExcaliburComponentSelector is as efficient as we can make it. We have a new ThreadSafe BucketMap class that helped out tremendously. The BucketMap synchronizes on a "bucket" or group of keys that fit the same hash value. Since the whole class is not synchronized, we can have acesses on the map using different keys without running into thread contention. Granted, the hash algorithm is a simple modulous: hash = object.hashCode() % m_buckets.length; If anyone has a cheap algorithm that distributes the hashes more evenly, please let me know. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]