These days, pure JavaScript tests won't do a lot of malloc() calls, so it's
more relevant to try a page load speed or DOM benchmark.
- Maciej
On Oct 4, 2013, at 6:10 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:
Hi,
As Zoltan said this feature was introduced for Qt port. But now
Hi,
As Zoltan said this feature was introduced for Qt port. But now
EFL, GTK and Nix use fastmalloc instead of system malloc too.
It was fine and used for some use-cases in those days.
To make a decision if the fastmalloc or the system malloc is better,
we need some measurements. I made a quick
02.10.2013, 03:18, Zoltan Horvath zol...@webkit.org:
On Tue, Oct 1, 2013 at 3:52 PM, Geoffrey Garen gga...@apple.com wrote:
So are you proposing to use the system allocator on Windows?
I’m proposing a two step process:
(1) Use the system allocator on Windows (and GTK).
(2) If a port
On Oct 2, 2013, at 1:17 AM, Konstantin Tokarev annu...@yandex.ru wrote:
Out of curiosity, what's wrong with linking whole application using WebKit
against tcmalloc or some other malloc implementation?
There are a lot of things wrong with that. Most of them depend on the platform.
On Mac, for
On Oct 2, 2013, at 1:17 AM, Konstantin Tokarev annu...@yandex.ru wrote:
02.10.2013, 03:18, Zoltan Horvath zol...@webkit.org:
On Tue, Oct 1, 2013 at 3:52 PM, Geoffrey Garen gga...@apple.com wrote:
So are you proposing to use the system allocator on Windows?
I’m proposing a two step
On Oct 2, 2013, at 2:41 AM, Andy Wingo wi...@igalia.com wrote:
We need somebody to resolve these issues, otherwise our memory
footprint will be unacceptably high, and/or our VM operations will be
unacceptably slow.
There is no memory footprint problem caused by mmap here -- to my
However, given the constraints, what's the problem with the mmap
strategy? Sure, you have more page tables on the kernel side, but
mmap'd memory that is never touched is never resident in a process. I
verified this a few months back when troubleshooting some memory-related
issues.
On Mon, Sep 30, 2013 at 7:41 PM, Zoltan Horvath zol...@webkit.org wrote:
Based on a 2.5-year-old measurement
(http://webkit.sed.hu/blog/20100302/war-allocators-qtlaunchers-coast) on the
Qt-port, the page loading on the Methanol test suite was 5% faster (avg)
with TCmalloc than the default
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?
Here’s a rough task list:
(1) Define a canonical GTK platform we’ll use
Here’s a rough task list:
(1) Define a canonical GTK platform we’ll use for performance measurement.
(2) Measure FastMalloc on/off on that platform.
Assuming FastMalloc is a significant improvement:
(1) Refactor GTK APIs so that API-level objects are not allocated/deleted by
global
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
On Sep 30, 2013, at 2:48 PM, Geoffrey Garen gga...@apple.com wrote:
Hi folks.
I’m planning to remove our years-out-of-date port of TCMalloc, and replace it
with something that takes maximum advantage of Mac and iOS virtual memory,
threading, and security APIs.
I've heard that TCMalloc
On Tue, Oct 1, 2013 at 11:34 AM, Geoffrey Garen gga...@apple.com wrote:
(4) Find a fast API for aligned virtual memory allocation.
(5) Find a fast API for committing / decommitting physical memory without
releasing virtual memory pages.
Hrm. Isn't this already available via OSAllocator or
On Tue, Oct 1, 2013 at 11:56 AM, Martin Robinson mrobin...@webkit.orgwrote:
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
(4) Find a fast API for aligned virtual memory allocation.
(5) Find a fast API for committing / decommitting physical memory without
releasing virtual memory pages.
Hrm. Isn't this already available via OSAllocator or are you referring
to the fact that the Posix implementation has a few
Apple's Windows port uses FastMalloc and the last measurements we took show
it to be a large performance gain over the default Windows malloc
implementation.
I believe those measurements were taken 5 Windows versions ago.
While this port is only used by iTunes these days, we still would
So are you proposing to use the system allocator on Windows? Or would we keep
using the existing FastMalloc implementation?
The current malloc logic has been the source of a number of mysterious crashes
on Windows, so reverting to the system allocator might be a good thing for
stability. I
On Oct 1, 2013, at 3:35 PM, Brent Fulgham bfulg...@apple.com wrote:
So are you proposing to use the system allocator on Windows? Or would we keep
using the existing FastMalloc implementation?
The current malloc logic has been the source of a number of mysterious
crashes on Windows, so
On Oct 1, 2013, at 3:05 PM, Geoffrey Garen gga...@apple.com wrote:
(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.
To access thread-specific data using pthreads, you first need to take a
On Oct 1, 2013, at 3:11 PM, Geoffrey Garen gga...@apple.com wrote:
(4) Find a fast API for aligned virtual memory allocation.
(5) Find a fast API for committing / decommitting physical memory without
releasing virtual memory pages.
Hrm. Isn't this already available via OSAllocator or are
To access thread-specific data using pthreads, you first need to take a lock
and call pthread_key_create(). Since the whole point of thread-specific data
is to avoid taking a lock, the API is useless.
The normal way to do it is to use pthread_once to create the key, which does
not in
So are you proposing to use the system allocator on Windows?
I’m proposing a two step process:
(1) Use the system allocator on Windows (and GTK).
(2) If a port maintainer cares to optimize a given port, without too much
disruption to mainline code, they may do so.
FWIW, If I were conducting
On Oct 1, 2013, at 3:47 PM, Geoffrey Garen gga...@apple.com wrote:
To access thread-specific data using pthreads, you first need to take a
lock and call pthread_key_create(). Since the whole point of
thread-specific data is to avoid taking a lock, the API is useless.
The normal way to do
On Tue, Oct 1, 2013 at 3:52 PM, Geoffrey Garen gga...@apple.com wrote:
So are you proposing to use the system allocator on Windows?
I’m proposing a two step process:
(1) Use the system allocator on Windows (and GTK).
(2) If a port maintainer cares to optimize a given port, without too
Hi folks.
I’m planning to remove our years-out-of-date port of TCMalloc, and replace it
with something that takes maximum advantage of Mac and iOS virtual memory,
threading, and security APIs.
I've heard that TCMalloc has caused some problems for non-Mac, non-iOS ports in
the past. So, if you
Hi Geoffrey,
I used to work on memory related topics, while I was working on the
University of Szeged.
Based on a 2.5-year-old measurement (
http://webkit.sed.hu/blog/20100302/war-allocators-qtlaunchers-coast) on the
Qt-port, the page loading on the Methanol test suite was 5% faster (avg)
with
26 matches
Mail list logo
