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 wrote:
> Hi,
>
> As Zoltan said this feature was introduced for Qt port. But now
> EFL, GTK and Nix use
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
> 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.
Okee
On Oct 2, 2013, at 2:41 AM, Andy Wingo 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
> knowledge. I
On Oct 2, 2013, at 1:17 AM, Konstantin Tokarev wrote:
>
> 02.10.2013, 03:18, "Zoltan Horvath" :
>> On Tue, Oct 1, 2013 at 3:52 PM, Geoffrey Garen wrote:
So are you proposing to use the system allocator on Windows?
>>>
>>> I’m proposing a two step process:
>>>
>>> (1) Use the system allo
On Oct 2, 2013, at 1:17 AM, Konstantin Tokarev 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 example, WebKit
Hi Geoffrey,
On Wed 02 Oct 2013 00:11, Geoffrey Garen writes:
> There are two problems with the current OSAllocator POSIX implementation:
>
> (1) It uses mmap, which doesn’t support aligned allocation. To get
> aligned allocation, POSIX double-allocates all virtual memory. That is
> 2X too much.
02.10.2013, 03:18, "Zoltan Horvath" :
> On Tue, Oct 1, 2013 at 3:52 PM, Geoffrey Garen 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 opti
On Tue, Oct 1, 2013 at 3:52 PM, Geoffrey Garen 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 much
> disru
On Oct 1, 2013, at 3:47 PM, Geoffrey Garen 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 it
> 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
>> 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
> no
On Oct 1, 2013, at 3:11 PM, Geoffrey Garen 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 you
On Oct 1, 2013, at 3:05 PM, Geoffrey Garen 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 lock
On Oct 1, 2013, at 3:35 PM, Brent Fulgham 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 reverting to the
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 don’
> 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
>> (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
>> (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 lock
and call pthread_key_create(). Since the whole point of threa
On Tue, Oct 1, 2013 at 11:56 AM, Martin Robinson 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 performanc
On Tue, Oct 1, 2013 at 11:34 AM, Geoffrey Garen 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 you referrin
On Sep 30, 2013, at 2:48 PM, Geoffrey Garen 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 has cause
On Oct 1, 2013, at 11:56 AM, Martin Robinson wrote:
> On Tue, Oct 1, 2013 at 11:33 AM, Geoffrey Garen 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 so
On Tue, Oct 1, 2013 at 11:33 AM, Geoffrey Garen 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 apprecia
> 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
> 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 fo
On Mon, Sep 30, 2013 at 7:41 PM, Zoltan Horvath 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 system allocator
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 TC
28 matches
Mail list logo
