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

Re: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs

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 (view raw or flat)
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


In response to

pgsql-hackers by date

Next:From: Christian UllrichDate: 2013-01-09 15:30:03
Subject: Re: PL/perl should fail on configure, not make
Previous:From: Tom LaneDate: 2013-01-09 15:16:04
Subject: Re: PL/perl should fail on configure, not make

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