Re: MemSet inline for newNode - Mailing list pgsql-patches

From Tom Lane
Subject Re: MemSet inline for newNode
Date
Msg-id 23824.1036986422@sss.pgh.pa.us
Whole thread Raw
In response to Re: MemSet inline for newNode  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: MemSet inline for newNode
List pgsql-patches
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> But your patch as committed does NOT inline newNode, in fact it does the
>> exact opposite: the MemSet macro is removed from the callsite.

> Yes, there were actually two patches;  the first inlined newNode by
> calling palloc0.  Without palloc, there was no way to inline newNode.

But you have *not* inlined newNode: the memset is still done at a location
that cannot know the size at compile time.

> The second was a more general one to merge palloc/MemSet into a single
> palloc0 call.  That has been backed out while I research it.

That part could be sold just on the basis of making the code easier
to read and less error-prone; particularly for call sites where the
length is a runtime computation anyway.  I think that newNode() is the
principal case where the length is knowable at compile time.  So my
feeling is that the general change to invent a palloc0() call is fine
... but if you want performance then newNode() should *not* be using the
generic palloc0() call.

> My new idea is to add a third boolean argument to
> MemoryContextAllocZero() which will control whether the MemSet
> assignment loop is used, or memset().

But we are *trying to eliminate any runtime test whatever*.  Short
of that, you aren't going to get the speedup.  Certainly passing a third
argument to the alloc subroutine will eat enough cycles to negate any
savings from simplifying the runtime test slightly.

            regards, tom lane

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: MemSet inline for newNode
Next
From: Bruce Momjian
Date:
Subject: Re: MemSet inline for newNode