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

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

In response to

Responses

Browse pgsql-general by date

  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