[
https://issues.apache.org/jira/browse/CASSANDRA-7030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13970297#comment-13970297
]
Vijay commented on CASSANDRA-7030:
----------------------------------
You are right i had the synchronization in the test attached in the old ticket
because initially we had some segfaults which was fixed in the later JEM
releases, but the synchronization was never committed into cassandra repo
because by then it was fixed.
Rerunning the test after removing the locks in the same old test classes, the
results the time take is much better in jemalloc, you might need more runs. The
memory foot print is better too (malloc is slower and uses more memory
comparatively as per my tests).
http://pastebin.com/JtixVvGU
As mentioned earlier i don't mind removing it either :)
> 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)
