[webkit-dev] WTF::fastMalloc

[Zoltan Horvath]

On Tue, Oct 1, 2013 at 11:56 AM, Martin Robinson <mrobinson at webkit.org>wrote:

>
> > Here’s a rough task list:
> >
> > (1) Define a canonical GTK platform we’ll use for performance
> measurement.
>
> Perhaps the University of Szeged team has some insight into what
> platforms they used for comparing allocator performance.


I measured the performance and memory for Qt on desktop and on some ARM
based embedded devices (e.g. Nokia N9). The blogs are still available on
the blog site, but I'm not sure we can consider the numbers as valid after
that many years. Please note also, I've working for Adobe for more than a
year now, so I don't know whether the University team has any recent public
results.

The goal for enabling TCmalloc on Qt/Gtk was to match the implementation
with the Apple port, which used TCmalloc at time. Please note also, only a
subset of QtWebKit platforms uses TCmalloc (linux, mac), the rest of them
still uses the default system allocator.

> (1) Refactor GTK APIs so that API-level objects are not allocated/deleted
> by global operator new/delete in WebCore+JavaScriptCore.
> >         (1a) Either build the API layer as a separate library from
> WebCore+JavaScriptCore,
> >         (1b) or specifically annotate each object at the API library
> with a per-class operator new / operator delete.
>
> I don't think this should be a problem. Currently all allocations of
> API-level objects happen with the GLib slab allocator (or system
> malloc/free, given the right environment arguments).
>
> > (2) Find a fast secure random number API on the canonical GTK platform.
>
> I can look into this.
>
> > (3) Find a fast thread-specific data API on the canonical GTK platform.
>
> Threading for GTK+ on non-Mac/non-Windows platforms is essentially
> pthreads. It probably wouldn't be a lot of work to defer to Windows
> and Mac implementations on those platforms.
>
> --Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131001/f76639c1/attachment.html>