<div dir="ltr"><div>Testing mixed read/write performance with capacity 100000, keys 300000, concurrency level 32, threads 12, read:write ratio 99:1<br>Container CHM Ops/s 5178894.77 Gets/s 5127105.82 Puts/s 51788.95 HitRatio 86.23 Size 177848 stdDev 60896.42<br>
Container CHMV8 Ops/s 5768824.37 Gets/s 5711136.13 Puts/s 57688.24 HitRatio 84.72 Size 171964 stdDev 60249.99<br><br></div><div>The test is probably limited by the 1% writes, but I think it does show that reads in CHMV8 are not slower than reads in OpenJDK7's CHM.<br>
</div><div>I haven't measured it, but the memory footprint should also be better, because it doesn't use segments any more.<br></div><div><br>AFAIK the memoryCHMV8 also uses copy-on-write at the bucket level, but we could definitely do a pure read test with a HashMap to see how big the performance difference is.<br>
</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 19, 2013 at 11:07 AM, Sanne Grinovero <span dir="ltr"><<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Why not. Only doubt I'd have is that other usages of the CHM are - I guess - services registry and similar configuration tools, for which write performance is irrelevant: your test measured puts, are there drawbacks on gets or memory usage? </p>
<p dir="ltr">Recently you changed all (most?) CHM creations to use a consistent factory, maybe we could improve on that by actually using a couple of factories which differentiate on the intended usage of the CHM: for example some maps who change very infrequently - mostly during boot or reconfiguration, maybe even topology change - could be better served by a non concurrent structure using copy-on-wrtite. </p>
<span class="HOEnZb"><font color="#888888">
<p dir="ltr">Sanne </p></font></span><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On 19 Apr 2013 08:48, "Dan Berindei" <<a href="mailto:dan.berindei@gmail.com" target="_blank">dan.berindei@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>+1 to make CHMv8 the default on JDK6 and JDK7<br><br></div><div>But I'm not convinced we should make it the default for JDK8 - even though we don't know exactly what we're getting with the JDK's implementation.<br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 19, 2013 at 5:39 AM, David M. Lloyd <span dir="ltr"><<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 04/18/2013 09:35 PM, Manik Surtani wrote:<br>
> Guys,<br>
><br>
> Based on some recent micro benchmarks I've been doing, I've seen:<br>
><br>
> MapStressTest configuration: capacity 100000, test running time 60 seconds<br>
> Testing mixed read/write performance with capacity 100,000, keys 300,000, concurrency level 32, threads 12, read:write ratio 0:1<br>
> Container CHM Ops/s 21,165,771.67 Gets/s 0.00 Puts/s 21,165,771.67 HitRatio 100.00 Size 262,682 stdDev 77,540.73<br>
> Container CHMV8 Ops/s 33,513,807.09 Gets/s 0.00 Puts/s 33,513,807.09 HitRatio 100.00 Size 262,682 stdDev 77,540.73<br>
><br>
> So under high concurrency (12 threads, on my workstation with 12 hardware threads - so all threads are always working), we see that Infinispan's CHMv8 implementation is 50% faster than JDK6's CHM implementation when doing puts.<br>
><br>
> We use a fair number of CHMs all over Infinispan's codebase. By default, these are all JDK-provided CHMs. But we have the option to switch to our CHMv8 implementation by passing in -Dinfinispan.unsafe.allow_jdk8_chm=true.<br>
><br>
> The question is, should this be the default? Thoughts, opinions?<br>
<br>
</div>The JDK's concurrency code - especially CHM - changes all the time.<br>
You'd be very well-served, in my opinion, to go with something like<br>
CHMv8 just because you could be so much more sure that you'll have more<br>
consistent (and possibly better, but definitely more consistent)<br>
performance across all JVMs, instead of being at the mercy of whatever<br>
particular implementation happens to run on whatever JVM.<br>
<span><font color="#888888"><br>
<br>
--<br>
- DML<br>
</font></span><div><div>_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div>
<br>_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br></blockquote></div>
</div></div><br>_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br></blockquote></div><br></div>