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

Re: inline newNode()

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: inline newNode()
Date: 2002-10-07 22:29:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> How much did you bloat the code?  There are an awful lot of calls to
> newNode(), so even though it's not all that large, I'd think the
> multiplier would be nasty.

The patch increases the executable from 12844452 to 13005244 bytes,
when compiled with '-pg -g -O2' and without being stripped.

> This isn't portable at all, AFAIK :-(.  Unfortunately I can't think
> of a portable way to do it with a macro, either.

Well, one alternative might be to provide 2 definitions of the
function -- one an extern inline in the header file, and one using the
current method (in a separate file, non-inline). Then wrap the header
file in an #ifdef __GNUC__ block, and the non-inlined version in
#ifndef __GNUC__. The downside is that it means maintaining two
versions of the same function -- but given that newNode() is pretty
trivial, that might be acceptable.

BTW, the GCC docs on inline functions are here:

According to that page, using 'static inline' instead of 'extern
inline' is recommended for future compatability with C99, so that's
what we should probably use (in the __GNUC__ version).



Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

In response to


pgsql-hackers by date

Next:From: Curtis FaithDate: 2002-10-07 23:04:58
Subject: Re: Analysis of ganged WAL writes
Previous:From: Alvaro HerreraDate: 2002-10-07 21:45:57
Subject: Re: 7.2.3 patching done

pgsql-patches by date

Next:From: Tom LaneDate: 2002-10-08 01:08:20
Subject: Re: inline newNode()
Previous:From: Kris JurkaDate: 2002-10-07 21:58:51
Subject: Re: DBMD Patch

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