Re: Re: performance hit with --enable-debug
| От | Tom Lane |
|---|---|
| Тема | Re: Re: performance hit with --enable-debug |
| Дата | |
| Msg-id | 26497.979494782@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: performance hit with --enable-debug ("Thomas T. Thai" <tom@minnesota.com>) |
| Ответы |
Re: Re: performance hit with --enable-debug
Re: Re: performance hit with --enable-debug |
| Список | pgsql-general |
"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.
regards, tom lane
В списке pgsql-general по дате отправления: