Hello Glaziers -
I've put together a test application to test locking performance in GlazedLists using the built-in locking vs. Java 5's locking. The results are pretty surprising. Bottom line first: 5.0 locks CRUSH the built-in locks. The build-in locks take almost 3 times as much time. Ok, now the details... My test apps does the following: - 2 writer threads, waiting between 0 and 10 ms between writes add a single Long per write - 20 reader threads, running as fast as they can get the size of the list & get a random item per read It runs for one minute and then reports how many read/writes we done and how much time the operations* took. *: Note, the timing for the operation includes acquiring the lock, doing the add or read, and releasing the lock. So, it tests more than the locking, but the access time should be constant since the only variable is the lock implementation. This timing was done on the following system: PowerMac G5 - 2x2.5 GHz Mac OS X 10.4.2 1.5 GB RAM VM was tuned with these options: -Dglazedlists.lockfactory.debug -verbose:gc -Xmx50m -Xms50m "Default Locks" is using the built-in Doug Lea-derived lock. "5.0 Locks" uses java.util.concurrent.locks.ReentrantReadWriteLock "5.0 Single Lock" uses java.util.concurrent.locks.ReentrantLock (same lock returned for read & write lock) Conclusions: - There's a significant performance gain to using Java 5's locking in thread-intensive environments. - The overhead of ReadWriteLocks appears to have been mostly removed in Java 5. I also the 1.4 equivalient of "5.0 Single Lock" where I ported Doug Lea's ReentrantLock class and used a single lock for reads and writes. Due to the heavy thread usage in this test case it performed horribly. I sort of expected that result with the "5.0 Single Lock" case too. No idea why it worked so much better. I'll check the test application in soon. Rob -- "Let your heart soar as high as it will. Refuse to be average." - A. W. Tozer --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Yo Rob --- Great work on the PDF, it looks like going to Java 5 locks will be quite compelling. Could you resend that jpg as a PDF - the resolution of the jpg makes it completely unreadable. As for my ongoing effort, building a Java parse tree is easy. But I'm having a hell of a time writing that tree back to disk. I really need something like DOM but for Java! Cheers, Jesse On 26-Jul-05, at 9:31 PM, Rob Eden wrote: > Hello Glaziers - > > I've put together a test application to test locking performance in > GlazedLists using the built-in locking vs. Java 5's locking. The > results are pretty surprising. > > > Bottom line first: 5.0 locks CRUSH the built-in locks. The build-in > locks take almost 3 times as much time. > > > Ok, now the details... > > My test apps does the following: > - 2 writer threads, waiting between 0 and 10 ms between writes > add a single Long per write > - 20 reader threads, running as fast as they can > get the size of the list & get a random item per read > It runs for one minute and then reports how many read/writes we > done and how much time the operations* took. > > *: Note, the timing for the operation includes acquiring the lock, > doing the add or read, and releasing the lock. So, it tests more > than the locking, but the access time should be constant since the > only variable is the lock implementation. > > This timing was done on the following system: > PowerMac G5 - 2x2.5 GHz > Mac OS X 10.4.2 > 1.5 GB RAM > VM was tuned with these options: > -Dglazedlists.lockfactory.debug > -verbose:gc > -Xmx50m > -Xms50m > > "Default Locks" is using the built-in Doug Lea-derived lock. > "5.0 Locks" uses java.util.concurrent.locks.ReentrantReadWriteLock > "5.0 Single Lock" uses java.util.concurrent.locks.ReentrantLock > (same lock returned for read & write lock) > > Conclusions: > - There's a significant performance gain to using Java 5's > locking in thread-intensive environments. > - The overhead of ReadWriteLocks appears to have been > mostly removed in Java 5. > > I also the 1.4 equivalient of "5.0 Single Lock" where I ported Doug > Lea's ReentrantLock class and used a single lock for reads and > writes. Due to the heavy thread usage in this test case it > performed horribly. I sort of expected that result with the "5.0 > Single Lock" case too. No idea why it worked so much better. > > I'll check the test application in soon. > > Rob > > <Locking.jpg> > > -- > > "Let your heart soar as high as it will. > Refuse to be average." > - A. W. Tozer > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] |
Oh sorry 'bout that. It was supposed to be a PDF. I don't know why it
was converted to a jpg. :-( The times are in nanoseconds, BTW. Rob On Jul 27, 2005, at 3:14 AM, Jesse Wilson wrote: > > Yo Rob --- > > Great work on the PDF, it looks like going to Java 5 locks > will be quite compelling. Could you resend that jpg as a PDF - > the resolution of the jpg makes it completely unreadable. > -- "Let your heart soar as high as it will. Refuse to be average." - A. W. Tozer --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Free forum by Nabble | Edit this page |