Re: [Fwd: Re: UnixWare 7.1.3 (BETA), C99 compiler,

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [Fwd: Re: UnixWare 7.1.3 (BETA), C99 compiler,
Дата
Msg-id 14810.1035821229@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [Fwd: Re: UnixWare 7.1.3 (BETA), C99 compiler,  (Larry Rosenman <ler@lerctr.org>)
Список pgsql-hackers
Larry Rosenman <ler@lerctr.org> forwards:
>>> My inclination is to change the code for ApplySortFunction to look like
>>> 
>>> #if defined(__GNUC__)
>>> __inline__
>>> #endif
>>> int32
>>> ApplySortFunction
>>> 
>>> so that the inline optimization only gets done for gcc, which we know
>>> interprets inline sanely.  Anyone see a better answer?
>> 
>> You've given us one source file.  Is ApplySortFunction() really called
>> from other files?  Another approach, assuming both this and that the
>> inlining is viewed as important for its three calls within this file,

Yup, both of those are correct: the performance-critical calls are in
the same file, but there are others.

>> to have a front end version of an internal function.  To wit:
>> 
>> static inline int32
>> StaticApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,
>> Datum datum1, bool isNull1,
>> Datum datum2, bool isNull2)
>> {
>> //etc.
>> }
>> 
>> int32
>> ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,
>> Datum datum1, bool isNull1,
>> Datum datum2, bool isNull2)

Grumble.  I suppose we have to do it that way, but it's really pretty
stupid.  Also, won't this fall foul of the original restriction
(ApplySortFunction referencing the static function myFunctionCall2)?
If not, why not?

> Until the open source base (and GCC) get around to matching the C99
> inline model,

Don't hold your breath... it looks like a net loss in functionality
for no gain, from where I sit.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Dave Page"
Дата:
Сообщение: Re: Request for supported platforms
Следующее
От: Jason Tishler
Дата:
Сообщение: Re: Request for supported platforms