Question

I have a simple scenario, I've inherited code where the build configurations have very different names than the standard configurations.

In particular, our "Production" configuration is more like our release configuration.

So I guess I have a few questions:

  1. What needs to be turned on or off, just so I can double check, to make something a "release" configuration? Things, like code optimization, debug symbols, etc.
  2. If code optimizations and such are turned on, are there any differences from the stock Release configuration, stuff that might be hard-coded at the JIT or compiler level?
  3. Outside of the stuff in item #1, and whats found in standard release configurations, is there anything else that should be enabled/disabled that would cause a noticeable performance impact, at the configuration level?
Was it helpful?

Solution

1 and 2 - there are very small difference between release and debug: optimizations are turned on (see what it means by Eric Lippert ) and there is no DEBUG defined for release build.

The easiest way to learn yourself how two configurations are different is to create basic project and compare configuration sections for debug and release.

Debug: Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' "

<Optimize>false</Optimize>
<DefineConstants>DEBUG;TRACE</DefineConstants>

Release: Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' "

<Optimize>true</Optimize>
<DefineConstants>TRACE</DefineConstants>

There is also difference in debug information type, but it mainly impact convenience of debugging.

3 - there is nothing else that is generic for all types of solution to improve performance. Each type of solutions have ways to tweak performance - correct logging configuration, options to compile related files in ASPX, NGen to pre-JIT, picking x86/x64... Basically you need to start doing regular performance work - set goals, measure, tweak/optimize.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top