.NET Tips and Tricks

Blog archive

Always Go to Production in Release Mode

I was at a client's site recently and watched them move the new version of their app to production by copying all the DLLs from the "staging" computer to the production computer. I commented on how that was the beauty of the .NET Framework: Once you had the application installed, upgrades could just consist of replacing the EXEs and DLLs. Of course, I added, you have to remember to do one last compile in Release mode before copying the DLLs.

My client said, "Pardon?" I said, "What!?!"

It turns out that, at my client's site, once a developer got their code working, my client just copied that developer's DLLs to the QA testing site. There's nothing wrong with that ... but my client was leaving money on the table as far as performance goes.

When you press F5 to start debugging, Visual Studio saves and compiles your application. However, that compile is a "fast and sloppy" one -- Visual Studio doesn't do any real optimization of your code. There are a couple of reasons for that. First, this "fast and sloppy" compile gets you into debug mode faster (which is good). Second, skipping optimization avoids rearranging, merging or even eliminating lines of your code, which some compiler optimizations can do. When you're stepping through your source code in debug mode, it's helpful if there's a one-to-one relationship between your source code and your compiled code which rearranging/merging/eliminating makes difficult.

However, when you move to production, you want all of those optimizations. I know that I've said elsewhere that the speed of business applications is controlled by their data access ... but for the cost of going up to the toolbar and changing that Solution Configuration's dropdown list setting from Debug to Release you can, potentially, get a significant improvement in your application's performance (my client estimated about a 10 percent reduction in average response time, for example).

You do have to remember to switch back to Debug mode after doing your "production compile." One of the other things that the Debug mode does is generate a .pdb file that supports debugging (among other things, it provides the relationship between your lines of source code and your compiled code). If you don't keep regenerating that file as you make changes to your source code, your debugging sessions will get decidedly weird.

Posted by Peter Vogel on 09/09/2016


comments powered by Disqus

Featured

  • Creating Reactive Applications in .NET

    In modern applications, data is being retrieved in asynchronous, real-time streams, as traditional pull requests where the clients asks for data from the server are becoming a thing of the past.

  • AI for GitHub Collaboration? Maybe Not So Much

    No doubt GitHub Copilot has been a boon for developers, but AI might not be the best tool for collaboration, according to developers weighing in on a recent social media post from the GitHub team.

  • Visual Studio 2022 Getting VS Code 'Command Palette' Equivalent

    As any Visual Studio Code user knows, the editor's command palette is a powerful tool for getting things done quickly, without having to navigate through menus and dialogs. Now, we learn how an equivalent is coming for Microsoft's flagship Visual Studio IDE, invoked by the same familiar Ctrl+Shift+P keyboard shortcut.

  • .NET 9 Preview 3: 'I've Been Waiting 9 Years for This API!'

    Microsoft's third preview of .NET 9 sees a lot of minor tweaks and fixes with no earth-shaking new functionality, but little things can be important to individual developers.

  • Data Anomaly Detection Using a Neural Autoencoder with C#

    Dr. James McCaffrey of Microsoft Research tackles the process of examining a set of source data to find data items that are different in some way from the majority of the source items.

Subscribe on YouTube