+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 investigation though. One of the main things to decide is weather jemalloc replaces all alloc's (as with LD_PRELOAD), or only MEM_* functions since this changes how its linked/bundled. How about make this a build option and give some time for platform maintainers to support, then default to ON when its working well? On Wed, May 11, 2011 at 9:47 PM, Tom M <letter...@gmail.com> wrote: > 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 <letter...@gmail.com> wrote: >> 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 <joe...@gmail.com> wrote: >> >>> Using jemalloc on all platforms might be the best approach, plugged >>> into guardedalloc. Integrating something like mempool or memarena in >>> CustomData is possible, but not ideal (given how much code it would >>> affect, and how close we are to trunk integration). >>> >>> Joe >>> _______________________________________________ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers