[infinispan-dev] Lock amortization preliminary performance numbers

[Vladimir Blagojevic]

On 2010-01-28, at 6:59 PM, Manik Surtani wrote:

> Can we think of a better way to generate keys here?  The problem with having random.nextInt() within the timed loop is that you are effectively measuring how quick your random impl is.  :)
> 
> Perhaps generate an array of random keys, and then have each thread just increment an offset on the array to get the key?  This offset could be a simple int, no need for an AtomicInt since the consequences of inaccuracy are just that you get a different random key, and the costs are unnecessary CAS.

Yes, I agree. This time I generated keys prior to looping. Key space was set to 50K and number of entries in read, write and remove arrays was 50K multiplied with loop factor. I used loop factor of 5. Therefore it is guaranteed that we will have repeated entries in those arrays. Note also that each array was generated independently but each map test used the same arrays. I thought that this setup represents real-life scenario a bit better - we will probably have large key space, however, all operations are going to be repeated over that key space over and over again. 

48 reader, 6 write and 4 remove threads were launched all together and they were given those arrays to execute operations sequentially by array index.  I ran each test 5 times for each map. I discarded lowest and largest vales and took an average of the remaining three. Results below. BCHM was bound by 512 entries and at the end of each test map sizes for ConcurrentHashMap and SynchronizedMap ranged between 25K and 42K. 

SynchronizedMap
get ops/ms 47, put ops/ms 38, remove ops/ms 51
BufferedConcurrentHashMap
get ops/ms 28509, put ops/ms 249, remove ops/ms 1559
ConcurrentHashMap
get ops/ms 10681, put ops/ms 438, remove ops/ms 1770

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100129/f7cf37ac/attachment-0002.html