Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What are the consequences of having "Optimize for debugging" enabled?

In visual studio there's an option called "Optimize for debugging" in the linker settings for a project:

Project Debug Options

By default it's set to "Optimize for debugging (/DEBUG)", even for the release configuration. Why is that? Does that change the built program in any way? Is there any disadvantage of having it enabled (Slower execution?)? Should I set this option to "No" before shipping a program? Or is it just to enable/disable generating the .pdb-debug file (=slower compile times when enabled)?

like image 660
Silverlan Avatar asked Mar 08 '23 21:03

Silverlan


2 Answers

The /DEBUG linker option has two immediate effects: link time as well as the amount of information available through the Program Database Files (.pdb).

  • /DEBUG:FASTLINK reduces link times, but only generates partial .pdb's. Private symbol information is left in the compilation products (libraries and object files). This option should be used, when those compilation products are available (usually when debugging an application that has been built on the local machine).
  • /DEBUG:FULL generates full .pdb's at the expense of (considerably) longer link times. This option is useful when you need to debug an application, where you don't have access to compilation products (libraries and object files). This is commonly used when an application has been deployed, where the .pdb's are stored alongside the source code in the SCM.

It is common to use the following settings:

  • Use /DEBUG:FASTLINK for debug builds. This reduces link times, and the partial .pdb's aren't an issue, because the compilation products with private symbol information are available.
  • Use /DEBUG:FULL for release builds that are about to be deployed. This generates full .pdb's required to debug applications that have been deployed, where the compilation products containing private symbol information are no longer available.
  • Do not use /DEBUG. The meaning of this switch has changed across versions of Visual Studio (defaults to /DEBUG:FULL for VS 2015, and /DEBUG:FASTLINK in VS 2017). Upgrading a project silently changes the interpretation of this linker setting, which may be undesirable.
like image 53
IInspectable Avatar answered Apr 08 '23 07:04

IInspectable


The problem at hand is where debug information is stored. The linked is provided with source object files, and these come with debug information. That information does not need to go into the executable. There are three options for the linker:

  • Simply ignore debugging information (/DEBUG:NONE)
  • Build a database of all debugging information, as a PDB file (/DEBUG:FULL)
  • Build a database of symbolic links to the object files (/DEBUG:FASTLINK).

Now, the option you see is just /DEBUG. That uses a default, which varies between VS releases. For VS2015, which you use, it means /DEBUG:FULL. You can now debug the EXE with the resulting PDB, even if you don't have the object files.

like image 40
MSalters Avatar answered Apr 08 '23 07:04

MSalters