[ https://issues.apache.org/jira/browse/CASSANDRA-7030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13968859#comment-13968859 ]
Benedict commented on CASSANDRA-7030: ------------------------------------- Nope, I copied that behaviour from your earlier ticket to make it as comparable as possible. Your code: {code} for (int i = 0; i < loops; i++) { long size = rand.nextInt(100); if (size <= 0) continue; tryMemory(size * 1024); } {code} I played with various multipliers, and I also tried with a completely uniform size distribution. I see no difference in results (uniform distribution of 64K sizes follow): {noformat} malloc: Items: 10M Elapsed: 2.911s Allocated: 2047Mb VM total:187 vsz: 3717 rsz: 2307 jemalloc: Items: 10M Elapsed: 23.869s Allocated: 2047Mb VM total:192 vsz: 4148 rsz: 2721 {noformat} That said, it would be interesting to see how jemalloc performs with JNI, rather than JNA. But as things stand, it doesn't seem a sensible option to offer, as it uses more memory and is slower. > Remove JEMallocAllocator > ------------------------ > > Key: CASSANDRA-7030 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7030 > Project: Cassandra > Issue Type: Improvement > Components: Core > Reporter: Benedict > Assignee: Benedict > Priority: Minor > Labels: performance > Fix For: 2.1 beta2 > > Attachments: 7030.txt > > > JEMalloc, whilst having some nice performance properties by comparison to > Doug Lea's standard malloc algorithm in principle, is pointless in practice > because of the JNA cost. In general it is around 30x more expensive to call > than unsafe.allocate(); malloc does not have a variability of response time > as extreme as the JNA overhead, so using JEMalloc in Cassandra is never a > sensible idea. I doubt if custom JNI would make it worthwhile either. > I propose removing it. -- This message was sent by Atlassian JIRA (v6.2#6252)