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

Andres Freund <andres@2ndquadrant.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