Re: jemalloc to replace default allocator
Re: jemalloc to replace default allocator
- Subject: Re: jemalloc to replace default allocator
- From: Jean-Daniel Dupas <email@hidden>
- Date: Sat, 8 May 2010 02:11:15 +0200
Le 7 mai 2010 à 22:30, Jens Alfke a écrit :
>
> On May 7, 2010, at 2:59 AM, Alastair Houghton wrote:
>
>> Why do that? My understanding is that jemalloc's primary advantage is massive scalability for heavily threaded code. Firefox isn't *that* heavily threaded, right?
>> In any event, the system allocator on Mac OS X has always been pretty good, and it looks like the Snow Leopard version is already designed with per-processor "magazines" for small allocations.
>
> Safari has long used a custom allocator (tcmalloc) for performance reasons. It makes a significant difference on standard browser benchmarks, I'm told, although I heard that before 10.6 came out. Chrome uses tcmalloc on Windows and Linux, and probably will eventually on Mac too.
>
> Neither of these goes as far as overriding malloc itself. Instead they define their own allocator functions and then use those instead of calling malloc directly. (Simply overriding ::operator new() gets you a lot of the way there, for a C++ app.)
>
> In the case of JavaScript (or other GC'd languages) you get the biggest speed boost from not using a normal allocator at all. The usage patterns of a GC system are very different because freeing blocks happens rarely and in huge batches. A typical GC allocator will allocate space by simply bumping a global pointer, and trigger a minor collection when the pointer hits the end of the space. This is one of the things that makes V8 fast.
I agree for Javascript. The OP didn't tell us it was for Javascript in its first mail.
As suggested sooner, if the bottleneck is in the Javascript library, it makes sense to use a custom allocator for this specific part. But I would not recommend replacing the default malloc for the whole application unless it proves useful.
-- Jean-Daniel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden