Re: [HACKERS] gperf anyone?

Поиск
Список
Период
Сортировка
От Alfred Perlstein
Тема Re: [HACKERS] gperf anyone?
Дата
Msg-id 20000118213249.R8736@fw.wintelcom.net
обсуждение исходный текст
Ответ на Re: [HACKERS] gperf anyone?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] gperf anyone?  (Michael Meskes <meskes@postgresql.org>)
Список pgsql-hackers
* Tom Lane <tgl@sss.pgh.pa.us> [000118 21:10] wrote:
> > At 07:36 PM 1/18/00 -0500, Bruce Momjian wrote:
> > I wondered about this last, i.e. the use of GNU code since Postgres
> > is licensed differently.
> 
> AFAIK this is no worse than using flex or bison --- the source code of
> gperf is GPL'ed, but its output is not.
> 
> Don Baccus <dhogaza@pacifier.com> writes:
> > Whether faster or slower, though, I can't imagine either method taking
> > noticably more than 0% of the total time to process a query, even the
> > most simple queries.
> 
> I agree with Don that the performance benefit is likely to be
> unmeasurable.  Still, there could be a win: we currently have to modify
> keywords.c by hand every time we have to add/delete a keyword.  Does
> gperf offer any aid for maintaining the keyword list?  If so, that'd
> be sufficient reason to switch to it...

any minimal performance boost shows over time, unfortunatly using gperf
will require that you either:

a) require gperf to be installed on a system that compiles postgresql
b) manually maintain the gperf compiled files in your CVS repo  (sort of like syscalls in FreeBSD)

Option B is not that bad at the expense of additional contributor
overhead.

I hope to be able to present some soft of bench to determine
if gperf is worth the additional effort of maintainance in the
near future.

in the meanwhile, happy hacking. :)

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]


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

Предыдущее
От: Vadim Mikheev
Дата:
Сообщение: Well...
Следующее
От: mr_hopkins@earthlink.net (Micheal H.)
Дата:
Сообщение: examples not included