Re: Re: performance hit with --enable-debug - Mailing list pgsql-general
From | Thomas T. Thai |
---|---|
Subject | Re: Re: performance hit with --enable-debug |
Date | |
Msg-id | Pine.NEB.4.21.0101141443540.889-100000@ns01.minnesota.com Whole thread Raw |
In response to | Re: Re: performance hit with --enable-debug (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: performance hit with --enable-debug
|
List | pgsql-general |
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.
pgsql-general by date: