From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs |
Date: | 2013-01-09 15:18:51 |
Message-ID: | 20130109151851.GC13084@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-01-09 11:45:12 -0300, Alvaro Herrera wrote:
>
> How hard is the backend hit by palloc being now an additional function
> call? Would it be a good idea to make it (and friends) STATIC_IF_INLINE?
Missed this at first...
I don't think there's any measurable hit now as there is no additional
function call as I chose to directly do the work directly in
palloc[0]. That causes a minor amount of code duplication but imo thats
ok. I didn't do that for pstrdup() but it would be easy enough to do it
there as well, but I don't think it matters there.
In a quick test I couldn't find any performance difference.
I don't think making them STATIC_IF_INLINE functions would help as I
think that would still require the CurrentMemoryContext symbol to be
visible in the callers context.
FWIW I previously measured whether the function call overhead via mcxt.c
is measurable and it wasn't...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Christian Ullrich | 2013-01-09 15:30:03 | Re: PL/perl should fail on configure, not make |
Previous Message | Tom Lane | 2013-01-09 15:16:04 | Re: PL/perl should fail on configure, not make |