[Rd] Help to create bugzilla account

[Steve Grubb]

On Saturday, August 12, 2017 5:36:36 PM EDT Dirk Eddelbuettel wrote:
> 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.

Depending on how this turns out, Fedora, RHEL, Centos also have jemalloc and 
tcmalloc. Meaning, if its good on those two, its good on Linux in general. 
Basically, jemalloc is faster for many work loads but its harder to spot 
problems. Glibc is better at spotting memory bugs but not as fast.

-Steve

> Anybody feel like doing some empirics?
> 
> Dirk