Thread: [COMMITTERS] pgsql: Add pg_noinline macro to c.h.
Add pg_noinline macro to c.h. Forcing a function not to be inlined can be useful if it's the slow-path of a performance critical function, or should be visible in profiles to allow for proper cost attribution. Author: Andres Freund Discussion: https://postgr.es/m/20170914061207.zxotvyopetm7lrrp@alap3.anarazel.de Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/a0247e7a11bb9f5fd55694b594a3906b7bd05881 Modified Files -------------- src/include/c.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Andres Freund <andres@anarazel.de> writes:
> Add pg_noinline macro to c.h.
I think you want this to be parenthesized so that pgindent doesn't
go nuts when you use it. At least, that was the reason why
pg_attribute_noreturn() has parens. Even if the current version
of pgindent doesn't have that problem, I would argue that consistency
demands that you spell this pg_attribute_noinline().
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On 2017-10-13 18:32:08 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > Add pg_noinline macro to c.h. > > I think you want this to be parenthesized so that pgindent doesn't > go nuts when you use it. At least, that was the reason why > pg_attribute_noreturn() has parens. Even if the current version > of pgindent doesn't have that problem The current pgindent actually generates *better* layout with pg_noinline rather than pg_noinline(). The latter forces a linebreak both in declarations and definitions like: static pg_noinline() HeapTuple SearchCatCacheMiss(CatCache *cache, static pg_noinline() HeapTuple SearchCatCacheMiss(CatCache *cache, One difference to pg_attribute_noreturn() is that for function definitions - and noinline needs to be present there IME - you can't put it after the parameter list. > I would argue that consistency demands that you spell this pg_attribute_noinline(). Hm, I personally find inline vs pg_noinline more aesthetically pleasing. Greetings, Andres Freund -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers