[Bf-committers] need help on vgroup/mdisp allocation

[Campbell Barton]

+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 <letterrip at 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 <letterrip at 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 <joeedh at 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 at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell