Skip site navigation (1) Skip section navigation (2)

Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Date: 2013-01-09 20:43:19
Message-ID: 1514.1357764199@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
I wrote:
> I then applied the palloc.h and mcxt.c hunks of your patch and rebuilt.
> Now I get an average runtime of 16666 ms, a full 2% faster, which is a
> bit astonishing, particularly because the oprofile results haven't moved
> much:

I studied the assembly code being generated for palloc(), and I believe
I see the reason why it's a bit faster: when there's only a single local
variable that has to survive over the elog call, gcc generates a shorter
function entry/exit sequence.  I had thought of proposing that we code
palloc() like this:

void *
palloc(Size size)
{
    MemoryContext context = CurrentMemoryContext;

    AssertArg(MemoryContextIsValid(context));

    if (!AllocSizeIsValid(size))
        elog(ERROR, "invalid memory alloc request size %lu",
             (unsigned long) size);

    context->isReset = false;

    return (*context->methods->alloc) (context, size);
}

but at least on this specific hardware and compiler that would evidently
be a net loss compared to direct use of CurrentMemoryContext.  I would
not put a lot of faith in that result holding up on other machines
though.

In any case this doesn't explain the whole 2% speedup, but it probably
accounts for palloc() showing as slightly cheaper than
MemoryContextAlloc had been in the oprofile listing.

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Stephen FrostDate: 2013-01-09 20:49:47
Subject: Re: Index build temp files
Previous:From: Bruce MomjianDate: 2013-01-09 20:42:25
Subject: Re: Feature Request: pg_replication_master()

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group