[
https://issues.apache.org/jira/browse/CASSANDRA-7030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict updated CASSANDRA-7030:
--------------------------------
Attachment: benchmark.21.diff.txt
bq. As mentioned earlier i don't mind removing it either
Well, if it demonstrates an advantage I'd prefer to keep it still :-)
Could you try running my benchmark, so we can compare the more specific stats,
and can rule out interference by CLHM? I'm particularly surprised that it is
anything like as fast, let alone faster, given how much dramatically slower it
is on my box (36MB/s is laughable). It's possible I have an older version of
jemalloc bundled with Ubuntu (I cannot run multi-threaded, but I think this is
down to compile options), but I assume the only explanation for such awful
performance is JNA.
I've attached a diff that should apply to 2.1.
> 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, benchmark.21.diff.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)
