These days, pure JavaScript tests won't do a lot of malloc() calls, so it's more relevant to try a page load speed or DOM benchmark.
- Maciej On Oct 4, 2013, at 6:10 AM, Osztrogonác Csaba <o...@inf.u-szeged.hu> wrote: > 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 <gga...@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? > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
