From edd at debian.org  Sat Aug 12 23:36:36 2017
From: edd at debian.org (Dirk Eddelbuettel)
Date: Sat, 12 Aug 2017 16:36:36 -0500
Subject: [Rd] Help to create bugzilla account
In-Reply-To: <alpine.DEB.2.20.1708121453120.4008@luke-Latitude>
References: <CAJdZCv3oUhwiqJUTwKy0ZvwkcB=qdA5WcBdfMsdAcJED9f356w@mail.gmail.com>
 <22925.47256.496267.20679@stat.math.ethz.ch>
 <CALEXWq1qcUU=cR-YT2fujXfB4HNd-7zJFdKhyuJ9icWRkV9-HQ@mail.gmail.com>
 <BB27F8C5-00DD-42D2-AD1E-5BB8E9E2AE81@r-project.org>
 <CAJdZCv0NAMf9qYodsondd5BHF1JSsP2G=wU63UXuTwfQahRmjA@mail.gmail.com>
 <alpine.DEB.2.20.1708121453120.4008@luke-Latitude>
Message-ID: <22927.29924.782435.781870@bud.eddelbuettel.com>


On 12 August 2017 at 15:10, luke-tierney at uiowa.edu wrote:
| As the Python posts poitns out, it is possible to use alternate malloc
| implementations, either rebuilding R to use them or using LD_PRELOAD.
| On Ubuntu for example, you can have R use jemalloc with
| 
| sudo apt-get install libjemalloc1
| env LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1 R
| 
| This does not seem to hold onto memory to the same degree, but I don't
| know about any other aspect of its performance.

Interesting.

I don't really know anything about malloc versus jemalloc internals but I can
affirm that redis -- an in-memory database written in single-threaded C for
high performance -- in its Debian builds has been using jemalloc for years,
presumably by choice of the maintainer. (We are very happy users of [a gently
patched] redis at work; lots of writes; very good uptime.)

Having the ability to switch to jemalloc, we could design a test bench and
compare what the impact is.

Similarly, if someone cared, I could (presumably) alter the default R build
for Debian and Ubunto to also switch to jemalloc.

Anybody feel like doing some empirics?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org



[Rd] Help to create bugzilla account
Dirk Eddelbuettel