Re: Re: performance hit with --enable-debug

Поиск
Список
Период
Сортировка
От Thomas T. Thai
Тема Re: Re: performance hit with --enable-debug
Дата
Msg-id Pine.NEB.4.21.0101141443540.889-100000@ns01.minnesota.com
обсуждение исходный текст
Ответ на Re: Re: performance hit with --enable-debug  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: performance hit with --enable-debug
Список pgsql-general
On Sun, 14 Jan 2001, Tom Lane wrote:
> "Thomas T. Thai" <tom@minnesota.com> writes:
> > figure out so i check my ./configure flags. and there it was
> > --enable-debug. after sending my email to the list, i recompiled w/o debug
> > and now i can get my results back from a query in less than 2
> > seconds. before it was 59 secs if it returned at all. size of postgres
> > went down from 11.5 MB to a little less than 3mb. overall things seem
> > faster for inserts and selects for newly started backends too.
>
> Exactly what compiler are you using?  On what platform?
>
> --enable-debug doesn't do *anything* except add -g to the compiler
> flags.  With gcc, that typically causes substantial bloat in the
> executable's file size (because of the debug symbol tables --- I get
> about a 20Meg executable of which 18Meg is symbol tables), but it's not
> supposed to change the generated code at all.  With non-gcc compilers,
> -g typically turns off compiler optimizations, but I wouldn't expect a
> 30x performance penalty from that.
>
> BTW, it appears to me that configure won't even add the -g unless it
> thinks the compiler is gcc ... ie, --enable-debug is a no-op on non-gcc
> compilers.  Peter, isn't that a bug?
>
> Tom, were you also using --enable-cassert?  That I would expect to cause
> a performance penalty, though not a large one.

no i didn't use --enable-cassert. i'm on NetBSD/Alpha 1.5.1-current egcs
1.1.2. another thing i forgot to mention was that i switched from
mnogosearch's crc-multi to cachemode. crc-multi heavily depended on sql
tables to search for words and url look ups. now in cachemode it only use
sql for url lookups and word is looked up via a tree structure very much
like the Squid proxer server method.

typically i have 8 or so indexers running in parallel SELECT-ing,
INSERT-ing, etc to pgsql. the disk is 90% busy most of the time because of
sql queries from the indexers. then i test and search for a word or words
via the web form, and measure the time it takes.

before with the 8 indexers running and mnogosearch in crc-multi, searching
for words was unusuable. often time resulting in nothing displayed because
the cgi would time out while postgres was still doing a select. this was
with mid-dec cvs pgsql source and mnogosearch 3.1.8 source as well.

now i'm running -current pgsql and mnogosearch without --enable-debug. so
that's a lot of variables to narrow down. but the important thing for me
is that i get fast responses. i suppose i could go back and eliminate some
variables to see what really helped with the speed up, but that's way too
much data to shuffle around and very time consuming on my part.


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: performance hit with --enable-debug
Следующее
От: "Thomas T. Thai"
Дата:
Сообщение: Re: stale portmaster processes