[webkit-dev] WTF::fastMalloc

[Osztrogonác Csaba]

Hi,

As Zoltan said this feature was introduced for Qt port. But now
EFL, GTK and Nix use fastmalloc instead of system malloc too.
It was fine and used for some use-cases in those days.

To make a decision if the fastmalloc or the system malloc is better,
we need some measurements. I made a quick test on EFL and Nix with
SunSpider and with the Methanol test suite and haven't seen any
significant performance differences between fastmalloc and system
malloc on my desktop: Ubuntu 12.04 (x86_64). I haven't checked the
memory consumption, it would need more preparation.

Keeping the old TCMalloc and the custom allocator framework isn't
blocker for us (University of Szeged), so we don't have objection
against removing it from trunk. If nodbody is interested in maintaining
the framework, it can be removed. If the final conclusion would be
dropping TCMalloc, we willingly help in this clean-up.

Ossy

Zoltan Horvath írta:
> I used to work on memory related topics, while I was working on the 
> University of Szeged.
> 
> Based on a 2.5-year-old measurement 
> (http://webkit.sed.hu/blog/20100302/war-allocators-qtlaunchers-coast) on 
> the Qt-port, the page loading on the Methanol test suite was 5% faster 
> (avg) with TCmalloc than the default system allocator on Linux. The 
> performance results of the SunSpider suite was similar for both 
> allocators. The memory consumption was always lower with the default os 
> allocator. 
> 
> I guess the new allocator only has iOS support. I'm fine with removing 
> TCmalloc, although this direction might raises further questions, like 
> removing the custom allocation framework also. Feel free to cc me on 
> bugs, I can help by contributing some patches. 

> On Mon, Sep 30, 2013 at 2:48 PM, Geoffrey Garen <ggaren at apple.com 
>     I'm planning to remove our years-out-of-date port of TCMalloc, and
>     replace it with something that takes maximum advantage of Mac and
>     iOS virtual memory, threading, and security APIs.
> 
>     I've heard that TCMalloc has caused some problems for non-Mac,
>     non-iOS ports in the past. So, if you maintain a port, this change
>     might make things simpler for you.
> 
>     Are there any ports whose built-in malloc implementations are slow
>     enough that they can't get by without TCMalloc?