Hi Mau, that for the explanation, that really helps on clarifying the graph!!!
I have an idea about merging the tests in trunk with a profile approach that I already submitted for the Disruptor project[1] - they have performance/benchmark tests too - if it is fine for you I can work on it - not today that's Rugby day, maybe tomorrow :) All the best and have a nice WE, Simo [1] http://code.google.com/p/disruptor/issues/detail?id=2 http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Oct 22, 2011 at 10:00 AM, Maurizio Cucchiara <mcucchi...@apache.org> wrote: > I almost forgot there are even old vs commons comparison. Stay tuned :) > > Twitter :http://www.twitter.com/m_cucchiara > G+ :https://plus.google.com/107903711540963855921 > Linkedin :http://www.linkedin.com/in/mauriziocucchiara > > Maurizio Cucchiara > > > > On 22 October 2011 09:58, Maurizio Cucchiara <mcucchi...@apache.org> wrote: >> Thank you Simo, >> Ok, I realized after that the graph needs at least a short explanation: >> In that test I have tried to test every caches which I re-engineered. >> In the graph you mentioned, there are depicted 3 different kind of >> cache implementations: >> 1. Concurrent HashMap (CHM) >> 2. Thread-safe HashMap (HM) >> 3. Reentrant Read Write Lock (RRWL) >> >> As you will notice, there are some cases where RRWL is faster, other >> where CHM and so on. >> So there is no yet a real winner approach, though, at very quick look, >> CHM seems to be the slower one (my guess is that it's the only >> not-fully thread safe). >> >> To answer your question about projects merging, they surely could work >> under the same project, my only concern is about the execution time. >> At the moment I'm writing the whole execution time is near 50 seconds >> (currently the non-benchmark side take more or less 20 seconds). >> Furthermore the benchmark tests don't give you an answer in term of >> correctness (aside from the concurrency issues), ATM the only >> motivation behind them is performance measurement. >> Next time I could check the hit/miss ratio. >> Twitter :http://www.twitter.com/m_cucchiara >> G+ :https://plus.google.com/107903711540963855921 >> Linkedin :http://www.linkedin.com/in/mauriziocucchiara >> >> Maurizio Cucchiara >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
