Re: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs
| От | Andres Freund | 
|---|---|
| Тема | Re: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs | 
| Дата | |
| Msg-id | 20130109151851.GC13084@awork2.anarazel.de обсуждение исходный текст  | 
		
| Ответ на | Re: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs (Alvaro Herrera <alvherre@2ndquadrant.com>) | 
| Список | 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
В списке pgsql-hackers по дате отправления: