I've got a build of my game that works on Windows under a release and debug build as expected. When I deploy the debug version of the game to the Xbox, it works as expected and runs the same as on Windows - however when I deploy the release version to the XBOX I get different behaviour within the game.

I'm using a 3rd party library for the collisions (which is where I am seeing differences between the release and debug versions of my game); so I can't see what's actually different but I suspect they have some compiler directive for Debug on the Xbox to the Release version on the Xbox.

As such, I'm thinking that I may need to release my game with the Debug build instead of the Release build but I want to know what issues I can expect by doing so? Are there any significant performance issues between the two build profiles?

  • \$\begingroup\$ Note that you generally are not allowed to ship debug versions of runtime (or other) library components, so often you cannot actually legally ship a debug version of a game unless you ensure that any dependencies either can have their debug version shipped or you use their release version instead. \$\endgroup\$ – user1430 May 27 '12 at 1:05
  • 2
    \$\begingroup\$ It also may be worth posting another question where you describe the specific behavior differences you are observing and ask why they might exist. \$\endgroup\$ – user1430 May 27 '12 at 1:06

One behavior I've seen happen regularly in Debug builds that doesn't happen in release builds: in Debug builds, 'uninitialized' memory (including notably the stack) tends to be memset to 0, and so in particular variables that aren't explicitly initialized will often start with a value of 0; in release mode builds this doesn't happen, so these variables are truly uninitialized and will have undefined values. While the compiler should warn you about usage of uninitialized variables, that doesn't always work across function boundaries, and that would be the first thing that I'd look for.

| improve this answer | |

In debug mode the compiler emits debug symbols for all variables and compiles the code as is. In release mode, generally some optimizations are included:

  • Unused variables do not get compiled at all
  • Some loop variables are taken out of the loop by the compiler if they are proven to be invariants
  • Code written under #debug directive is not included.

As for performance, there is probably a very slim margin of 1-2% if at all, usually it runs just the same. Essentially though a release version is when you're done with the game, all bugs are worked out, and its what you release, hence the name.

But there is no significant performance change though. On the other hand though, significant performance change is possible, due to the number of tools available at compile time for the JIT.

Due to different [Debugger] attributes emitted by the compiler. (RELEASE is IgnoreSymbolStoreSequencePoints, DEBUG is EnableEditAndContinue). This attribute does limit the number of 'tools' that the JITter is allowed to use at runtime. In addition the JITter will NOT inline on DEBUG builds

Gotten mostly from this question here: https://stackoverflow.com/questions/2446027/c-sharp-debug-vs-release-performance/2446062#2446062 as well the comment to my answer by Jonathan Dickinson (Thank you for adding that)

Also read comments, and thanks to Drackir for pointing it out.

| improve this answer | |
  • 6
    \$\begingroup\$ If you're going to copy most of an answer from SO or another site you should link to it as well. Also, in the comments on that answer, there's a link to a much more in-depth analysis of what happens when the /optimize switch is used. It's definitely worth mentioning in your answer. \$\endgroup\$ – Richard Marskell - Drackir May 26 '12 at 23:34
  • \$\begingroup\$ sorry, i'll edit my answer right now \$\endgroup\$ – Rivasa May 26 '12 at 23:40
  • 2
    \$\begingroup\$ Depending on the code there can be quite a significant change. This is because of the different [Debugger] attributes emitted by the C# compiler (RELEASE is IgnoreSymbolStoreSequencePoints, DEBUG is EnableEditAndContinue). This attribute does limit the number of 'tools' that the JITter is allowed to use at runtime. In addition the JITter will NOT inline on DEBUG builds. -1 until that is ammended. gist.github.com/2802386 \$\endgroup\$ – Jonathan Dickinson May 27 '12 at 6:18
  • \$\begingroup\$ For performances I think it can vary alot depending what you do. I've seen 20%+ increase in performance. \$\endgroup\$ – DogDog Jul 27 '12 at 18:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.