[
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)
