performance of release vs debug build

Hi,
Up until now I have been shipping debug builds of my asp.net
application and including the pdb files too, even into production
systems, primarily because it gives us proper stack traces with line
numbers in the event of an exception. I haven't been aware of any
stability, memory or performance problems with the application, even
for sites that have been running 24/7 for months with worker process
recycling disabled.
is there any reason I shouldn't continue doing this indefinitely and
only switch to release builds if a customer needs a really highly
tuned system, or are there some gotchas with debug builds?
a related question - any general guidelines as to how much faster C#
code performs in release build? as for most asp.net apps I would
anticipate that the system load of the application as a whole is
probably 50% IIS/franework, 50% database and only a miniscule amount
for my processing.
cheers
AndyHi,
See:
http://weblogs.asp.net/scottgu/arch...0_-enabled.aspx
Note also the followup link in the post.
Teemu Keiski
AspInsider, ASP.NET MVP
http://blogs.aspadvice.com/joteke
http://teemukeiski.net
<ajfish@.blueyonder.co.uk> wrote in message
news:1178872287.825311.58920@.h2g2000hsg.googlegroups.com...
> Hi,
> Up until now I have been shipping debug builds of my asp.net
> application and including the pdb files too, even into production
> systems, primarily because it gives us proper stack traces with line
> numbers in the event of an exception. I haven't been aware of any
> stability, memory or performance problems with the application, even
> for sites that have been running 24/7 for months with worker process
> recycling disabled.
> is there any reason I shouldn't continue doing this indefinitely and
> only switch to release builds if a customer needs a really highly
> tuned system, or are there some gotchas with debug builds?
> a related question - any general guidelines as to how much faster C#
> code performs in release build? as for most asp.net apps I would
> anticipate that the system load of the application as a whole is
> probably 50% IIS/franework, 50% database and only a miniscule amount
> for my processing.
> cheers
> Andy
>
Thanks very much for these links
it seems to me that we can continue to use a debug build for the code
in the application without too much penalty, but should definitely use
debug=false in the web.config
On 11 May, 10:08, "Teemu Keiski" <jot...@.aspalliance.com> wrote:
> Hi,
> See:[url]http://weblogs.asp.net/scottgu/archive/2006/04/11/Don_1920_t-run-prod...[/ur
l]
> Note also the followup link in the post.
> --
> Teemu Keiski
> AspInsider, ASP.NET MVPhttp://blogs.aspadvice.com/jotekehttp://teemukeiski
.net
> <ajf...@.blueyonder.co.uk> wrote in message
> news:1178872287.825311.58920@.h2g2000hsg.googlegroups.com...
>
>
>
>
>
>
>
> - Show quoted text -
Yup, that's what Scott says to be a sort of "compromise"
Teemu
<ajfish@.blueyonder.co.uk> wrote in message
news:1178876244.123360.92750@.e65g2000hsc.googlegroups.com...
> Thanks very much for these links
> it seems to me that we can continue to use a debug build for the code
> in the application without too much penalty, but should definitely use
> debug=false in the web.config
> On 11 May, 10:08, "Teemu Keiski" <jot...@.aspalliance.com> wrote:
>