On Tue, Oct 1, 2013 at 11:56 AM, Martin Robinson <mrobin...@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 >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
