maniccoder

4 ms·

1.
Rpmalloc – a faster memory allocator (new release)
3 points by maniccoder 10y ago|0 comments
2.
by maniccoder 10y ago
Thank you for the clarifications, I will definitely improve the documentation w.r.t trouble cases, fragmentation and similar allocators. The goal is of course not to replace the standard allocator, but rather to offer an alternative for tho
3.
by maniccoder 10y ago
https://github.com/rampantpixels/rpmalloc/issues/6
4.
by maniccoder 10y ago
Memory blocks are owned by the span (the page-aligned larger bucket of blocks) they belong to. While a span is in use (at least on block is allocated) it is indeed owned by the heap that allocates the block. When the span is completely free
5.
by maniccoder 10y ago
There already is a benchmark against glibc single threaded, compile the rpmalloc-benchmark repository linked in the readme and run the runall script. Compare rpmalloc 1 thread case against crt 1 thread (with crt being the C runtime, i.e gli
6.
by maniccoder 10y ago
I will look into it
7.
by maniccoder 10y ago
Yes, you can (unless you also include the provided malloc.c glue code which provides the malloc family of entry points - only use the rpmalloc.c implementation). However, read the caveat section in the readme if you're on a mmap based
8.
by maniccoder 10y ago
I'm going to add jemalloc, lockless and scalloc in the benchmark comparisons soon(ish). Regarding the files, only rpmalloc.[h|c] is needed. The malloc.c file is just for overriding the malloc family of entry points, and provide automat
9.
by maniccoder 10y ago
It does not, at the moment. Feel free to create an issue about it on the github repo, or even submit a PR if you're feeling creative.
10.
by maniccoder 10y ago
What specifically would you like to know? I would be happy to elaborate more in the readme if you can explain in more detail what you mean with "insufficient analysis". The reason I posted about it on twitter in the first place wa