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]
