commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@centras.lt>
Subject Re: [Collections] StaticBucketMap not thread safe
Date Wed, 26 Jun 2002 21:27:23 GMT
There are found a lot of interesting things with performance tests on JVM :)
May be disable GC for tests ?
I testing with my Set implementation and HashSet, I  trieing to implement
"faster"
without synchronization first, but I can't write a good test for both
implementations,
results more depend on test not on implementation. Some are good for numbers
returned from Random, some for something like "Autoincrement" in database
.... .


> > From: Juozas Baliuka [mailto:baliuka@centras.lt]
> >
> > Yes, It must test both cases new Integer( i*x )( or new
> > Integer( i + i ) ) and new Integer( nextRandom ) to test hash
> > dispertion. It is not very trivial to write good test for
> > thing like this.  And try to run all test cases not in the
> > same process, 20 times for BusketMap, 20 for HashMap .... .
>
>
> In my current iteration, I have split the testcases so that we
> have one test per process.  I found that I get inconsistent results
> unless I call System.gc() before and after the test is done.
>
> RE: the testing of hash dispersal:
>
> We loop from 0 to ITERATIONS / 2 twice.
>
> The first loop tests the put.
> The second loop tests the get.
>
> The put loop tests the key new Integer (i) (value is set to i*5).
> The get loop tests the key new Integer (i*5) (value undetermined...).
>
> Would it be better if we changed the loop to something like this:
>
>         public void run()
>         {
>             int seed = 0;
>             Random rnd = new Random(seed);
>
>             for( int i = 0; i < this.mapCount / 4; i++ )
>             {
>                 this.map.put(new Integer( i ), new Integer( i * 5 ) );
>                 this.count++;
>                 this.map.put(new Integer(rnd.nextInt()), new
> Integer(rnd.nextInt()) );
>                 this.count++;
>             }
>
>             rnd.setSeed(seed);
>
>             for( int i = 0; i < this.mapCount / 4; i++ )
>             {
>                 Integer value = (Integer)this.map.get( new Integer( i *
> 5 ));
>                 this.count++;
>                 value = (Integer)this.map.get( new Integer(
> rnd.nextInt() ));
>                 this.count++;
>             }
>         }
>
>
> It takes the (i*5) and the random values into consideration.
>
> The results are something like this (20 threads):
>
>     [junit] BucketMap (5001 buckets) took 200ms
>     [junit] Thats 0.0010ms per operation
>     [junit] Unsized BucketMap (255 buckets) took 280ms
>     [junit] Thats 0.0014ms per operation
>     [junit] Synchronized (sized) HashMap took 831ms
>     [junit] Thats 0.004155ms per operation
>     [junit] Synchronized (unsized) HashMap took 761ms
>     [junit] Thats 0.003805ms per operation
>     [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 3.044
> sec
>     [junit] Testsuite:
> org.apache.avalon.excalibur.collections.test.ThreadedMapTest
>     [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 3.044
> sec
>
>
> I find it interesting that the unsized version of HashMap
> is more performant than the sized version.
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message