Thread: performance hit with --enable-debug

performance hit with --enable-debug

From
"Thomas T. Thai"
Date:
what kind of performance hit would i endure if i compiled with
--enable-debug on -current


Re: performance hit with --enable-debug

From
Peter Eisentraut
Date:
Thomas T. Thai writes:

> what kind of performance hit would i endure if i compiled with
> --enable-debug on -current

The effect in terms of query execution speed is probably minimal.  The
problem is that the executables get about 15% larger, which can lead to
longer load times, more memory usage, and ultimately to some speed issues.
Personally, I wouldn't worry about it too much, especially if you're
running beta and want to track down potential bugs.

--
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Re: performance hit with --enable-debug

From
"Thomas T. Thai"
Date:
On Sun, 14 Jan 2001, Peter Eisentraut wrote:

> Thomas T. Thai writes:
>
> > what kind of performance hit would i endure if i compiled with
> > --enable-debug on -current
>
> The effect in terms of query execution speed is probably minimal.  The
> problem is that the executables get about 15% larger, which can lead to
> longer load times, more memory usage, and ultimately to some speed issues.
> Personally, I wouldn't worry about it too much, especially if you're
> running beta and want to track down potential bugs.

i'm running mnogosearch along with pgsql-current. and performance have
been just terrible to get results back on a resonable time. i couldn't
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.


Re: performance hit with --enable-debug

From
Bruce Momjian
Date:
> Thomas T. Thai writes:
>
> > what kind of performance hit would i endure if i compiled with
> > --enable-debug on -current
>
> The effect in terms of query execution speed is probably minimal.  The
> problem is that the executables get about 15% larger, which can lead to
> longer load times, more memory usage, and ultimately to some speed issues.
> Personally, I wouldn't worry about it too much, especially if you're
> running beta and want to track down potential bugs.

Not sure about the longer load times.  Once the postmaster is loaded and
the first postgres client, all the pages are probably faulted in at that
point.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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

From
Bruce Momjian
Date:
> i'm running mnogosearch along with pgsql-current. and performance have
> been just terrible to get results back on a resonable time. i couldn't
> 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.

Wow, now there is a good testimonial to not run production stuff with
debug enabled.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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

From
Tom Lane
Date:
"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

Re: performance hit with --enable-debug

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> The effect in terms of query execution speed is probably minimal.  The
>> problem is that the executables get about 15% larger, which can lead to
>> longer load times, more memory usage, and ultimately to some speed issues.

> Not sure about the longer load times.

I don't believe that either.  The debug symbol tables aren't part of the
memory-resident image, they just sit out there on disk ... at least in
Unixen that I'm familiar with.

I think this is worth looking at more closely.  I can't see any reason
that Tom should be seeing a 30x performance hit from --enable-debug;
there's something going on here that I don't understand.

            regards, tom lane

Re: performance hit with --enable-debug

From
Bruce Momjian
Date:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> The effect in terms of query execution speed is probably minimal.  The
> >> problem is that the executables get about 15% larger, which can lead to
> >> longer load times, more memory usage, and ultimately to some speed issues.
>
> > Not sure about the longer load times.
>
> I don't believe that either.  The debug symbol tables aren't part of the
> memory-resident image, they just sit out there on disk ... at least in
> Unixen that I'm familiar with.
>
> I think this is worth looking at more closely.  I can't see any reason
> that Tom should be seeing a 30x performance hit from --enable-debug;
> there's something going on here that I don't understand.

I believe Peter was discussing image size, which while it affects the
binary size, it sits at the end of the binary and never gets loaded from
disk.

I believe debug adds some addition checks in the code, and that is why
he is seeing slowness with debug.  It was not the -g flag he used but
--enable-debug.  I just looked at configure.in, and saw the
--enable-debug enables assert checking.


--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: performance hit with --enable-debug

From
Peter Eisentraut
Date:
Bruce Momjian writes:

> I believe debug adds some addition checks in the code, and that is why
> he is seeing slowness with debug.  It was not the -g flag he used but
> --enable-debug.  I just looked at configure.in, and saw the
> --enable-debug enables assert checking.

I don't think so.

--
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


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

From
Peter Eisentraut
Date:
Tom Lane writes:

> 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?

In case you're referring to

if test "$enable_debug" = yes && test "$ac_cv_prog_cc_g" = yes; then
  CFLAGS="$CFLAGS -g"
fi

this has nothing to do with GCC.  $ac_cv_prog_cc_g is set to yes if the
compiler understands -g.

--
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


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

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> 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?

> In case you're referring to

> if test "$enable_debug" = yes && test "$ac_cv_prog_cc_g" = yes; then
>   CFLAGS="$CFLAGS -g"
> fi

> this has nothing to do with GCC.  $ac_cv_prog_cc_g is set to yes if the
> compiler understands -g.

My mistake, looked at "prog_cc_g" and saw "prog_gcc" :-(

            regards, tom lane

Re: performance hit with --enable-debug

From
Bruce Momjian
Date:
> Bruce Momjian writes:
>
> > I believe debug adds some addition checks in the code, and that is why
> > he is seeing slowness with debug.  It was not the -g flag he used but
> > --enable-debug.  I just looked at configure.in, and saw the
> > --enable-debug enables assert checking.
>
> I don't think so.

Sorry, you are right.  I misread the file.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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

From
"Thomas T. Thai"
Date:
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.


Re: performance hit with --enable-debug

From
Tom Lane
Date:
"Thomas T. Thai" <tom@minnesota.com> writes:
> 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.

I'm not familiar with mnogosearch, but I'll bet that that last change is
the one that made the difference.  Since you're using egcs, whether -g
is there or not really shouldn't make any measurable performance
difference.

            regards, tom lane

Re: performance hit with --enable-debug

From
Patrick Welche
Date:
On Sun, Jan 14, 2001 at 12:58:16PM -0500, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> The effect in terms of query execution speed is probably minimal.  The
> >> problem is that the executables get about 15% larger, which can lead to
> >> longer load times, more memory usage, and ultimately to some speed issues.
>
> > Not sure about the longer load times.
>
> I don't believe that either.  The debug symbol tables aren't part of the
> memory-resident image, they just sit out there on disk ... at least in
> Unixen that I'm familiar with.
>
> I think this is worth looking at more closely.  I can't see any reason
> that Tom should be seeing a 30x performance hit from --enable-debug;
> there's something going on here that I don't understand.

I suppose something to try is compile with --enable-debug, then strip the
resultant executable, and see if it is as fast as (should be identical to?)
executable generated without --enable-debug..

Cheers,

Patrick