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. > (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
