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

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: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Date: 2013-01-09 22:28:35
Message-ID: 3939.1357770515@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-01-09 15:43:19 -0500, Tom Lane wrote:
>> 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.

> Thats not optimized to the same? ISTM the compiler should produce
> exactly the same code for both.

No, that's exactly the point here, you can't just assume that you get
the same code; this is tense enough that a few instructions matter.
Remember we're considering non-assert builds, so the AssertArg vanishes.
So in the form where CurrentMemoryContext is only read after the elog
call, the compiler can see that it requires but one fetch - it can't
change within the two lines where it's used.  In the form given above,
the compiler is required to fetch CurrentMemoryContext into a local
variable and keep it across the elog call.  (We know this doesn't
matter, but gcc doesn't; this version of gcc apparently isn't doing much
with the knowledge that elog won't return.)  Since the extra local
variable adds several instructions to the overall function's entry/exit
sequences, you come out behind.  At least on this platform.  On other
machines with different code generation behavior, the story could easily
be very different.

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

> I'd guess that a good part of the cost is just smeared across all
> callers and not individually accountable to any function visible in the
> profile.

Yeah, I think this is most likely showing that there is a real,
measurable cost of code bloat.

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2013-01-09 22:35:15
Subject: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Previous:From: Andres FreundDate: 2013-01-09 22:22:29
Subject: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

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