From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Thomas T(dot) Thai" <tom(at)minnesota(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Re: performance hit with --enable-debug |
Date: | 2001-01-14 17:53:02 |
Message-ID: | 26497.979494782@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Thomas T. Thai" <tom(at)minnesota(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-01-14 17:58:16 | Re: performance hit with --enable-debug |
Previous Message | Bruce Momjian | 2001-01-14 17:39:55 | Re: Re: performance hit with --enable-debug |