Thread: performance hit with --enable-debug
what kind of performance hit would i endure if i compiled with --enable-debug on -current
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/
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.
> 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
> 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
"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
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
> 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
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/
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/
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
> 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
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.
"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
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