oliver at apple.com
Tue Oct 1 12:00:43 PDT 2013
On Oct 1, 2013, at 11:56 AM, Martin Robinson <mrobinson at webkit.org> wrote:
> On Tue, Oct 1, 2013 at 11:33 AM, Geoffrey Garen <ggaren at 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.
>> (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.
More information about the webkit-dev