Re: Re: performance hit with --enable-debug - Mailing list pgsql-general

From Tom Lane
Subject Re: Re: performance hit with --enable-debug
Date
Msg-id 26497.979494782@sss.pgh.pa.us
Whole thread Raw
In response to Re: performance hit with --enable-debug  ("Thomas T. Thai" <tom@minnesota.com>)
Responses Re: Re: performance hit with --enable-debug  (Peter Eisentraut <peter_e@gmx.net>)
Re: Re: performance hit with --enable-debug  ("Thomas T. Thai" <tom@minnesota.com>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: performance hit with --enable-debug
Next
From: Tom Lane
Date:
Subject: Re: performance hit with --enable-debug