[
https://issues.apache.org/jira/browse/CASSANDRA-7030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13968529#comment-13968529
]
Benedict commented on CASSANDRA-7030:
-------------------------------------
Hmm. Interesting, I didn't expect there to be such a dramatic difference in
actual memory utilisation (some, but not much), only in allocation speed.
That is quite problematic for use-cases where you want to allocate small and
often - 3 micros per call makes it much too expensive for per-cell operations.
However for the row cache it's probably quite acceptable.
Do you still have the benchmark that you were running? Would be nice to see if
we could figure out why it was wasting so much memory - fragmentation doesn't
seem an adequate explanation for so many GBs (not saying it's not, just seems
quite extreme without specifically trying to break the algorithm).
> 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)
