+1 for using jemalloc, for durian we used it for all systems + the
render farm & it saved a lot of ram.
see: http://www.sintel.org/development/memory-jemalloc/
for *nix we can LD_PRELOAD jemalloc, so no special requirements other
then starting blender from a shell script,
windows needs some invest
Hi
jemalloc looks like a good solution,
still, to compare - few other links which deal with memory allocators with
variable size allocations.
http://wkaras.webs.com/heapmm/heapmm.html
http://g.oswego.edu/dl/html/malloc.html
http://shm-arena.sourceforge.net/
http://www.sqlite.org/malloc.html
ht
Of additional interest is that since firefox facebook has made a
number of improvements
http://www.facebook.com/notes/facebook-engineering/scalable-memory-allocation-using-jemalloc/480222803919
LetterRip
On Wed, May 11, 2011 at 12:41 PM, Tom M wrote:
> Here are some useful jemalloc links
>
> h
Here are some useful jemalloc links
http://www.canonware.com/jemalloc/
http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/
LetterRip
On Wed, May 11, 2011 at 12:32 PM, joe wrote:
> Using jemalloc on all platforms might be the best approach, plugged
> into guardedalloc. Integrating someth
A while back, testers of bmesh were complaining of performance issues
related to vgroup and mdisp allocation. I wrote a temporary fix
(BLI_cellalloc.h/c) but it's too evil for trunk. The basic problem is
how vgroups/mdisps overuse the system allocator. The optimal solution
would be to compile wi
