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