On Oct 1, 2013, at 11:56 AM, Martin Robinson <mrobin...@webkit.org> wrote:
> On Tue, Oct 1, 2013 at 11:33 AM, Geoffrey Garen <gga...@apple.com> wrote: >>> A 5% regression in page load performance seems pretty serious. >> >> I’m assuming you’re considering the GTK port here, and not the end-of-life >> Qt port. >> >> Are you up for some engineering work to adopt a better malloc for GTK? > > I appreciate your offer! > >> 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. > >> (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. WTF has a custom implementation of arc4random(), i suspect most current Gtk host environments have a native one as well (s_rand on windows is terribly slow, but like i said, WTF has its own secure generator that will seed appropriately) > >> (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. I recall linux having fast thread locals, as does windows. --Oliver _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
