2

Is it possible to specify certain blocks of code for which I do not wish debug symbols to be generated while in Debug build in VC++ 2010? So these parts can run at optimised speed, while other (logic) code blocks can be debugged?

The reason is I have to read an input file with million+ lines which is painfully slow in Debug mode, but I wouldn't like to use a smaller sample input file.

Cheers, Mike

  • 1
    You could move your input handling code to a separate library project, build that as non-debug, link it into your main project, and compile your main project as debug. – Merlyn Morgan-Graham Jun 09 '11 at 04:47
  • @Merlyn: Thanks for the tip. So there isn't some sort of `pragma` you can use? I'm not really sure how to go about making the input loop a separate library or linking it –  Jun 09 '11 at 04:51
  • @Benjamin: I added it as an answer. I am hoping there is a better alternative, and it seems schmichael is too :) – Merlyn Morgan-Graham Jun 09 '11 at 04:59

2 Answers2

5

A couple suggestions:

  • each C or C++ file can have options specified separately - that's obvious when you're using the command line to compile, but you can also do so in the IDE. There's no need to set up a separate project. Just right click on the file you want to have 'special' settings for and select "Properties". The big drawback to this is that it's not obvious that a particular file has different settings from the project settings, so it can be confusing when things don't seem to build like you expect after you've forgotten about the file-specific properties that have been set.
  • you can try the optimize pragma (http://msdn.microsoft.com/en-us/library/chh3fb0k.aspx) to see if it will do what you want

Note that symbol generation and optimization are separate things - optimized code can have symbols generated without hurting optimization (but due to the optimizations the debugger might still be confused tracing through or setting breakpoints). But there's not much reason to try to suppress symbols for specific files (except maybe for obfuscation purposes).

Some additional things to be aware of are that there are also differences between the debug and non-debug runtimes - and you can link to only one or the other. So, if the slowness you want to get rid of is in the debug runtime, you'll have to link to the non-debug runtime which might hamper you debugging in other areas. If you're using C++ there is also the issue of debugging and safe iterators (controlled by the _HAS_ITERATOR_DEBUGGING and _SECURE_SCL macros) - you can't mix and match code that's been compiled with different settings for these iterator configurations (see Visual Studio debug iterators).

Community
  • 1
  • 1
Michael Burr
  • 333,147
  • 50
  • 533
  • 760
  • I must admit I don't know very much at all about how the debugging process works, only how to use it (in my limited way) in every day activities. What I know is that a loooong loop runs very slowly when i Debug build, but not Release build. Therefore I just want to have the loop complete faster, but still be able to debug the other code. In the simplest way possible, even if not **the** fastest, just to make debugging bearable –  Jun 09 '11 at 07:48
  • 1
    +1. @schmichael: What he said about optimizing, while still generating symbols is right on the money. You may want to look into the command line compiler options, particularly relating to symbols and optimization. – Merlyn Morgan-Graham Jun 09 '11 at 08:00
  • @schmichael: I've added a couple of thoughts to the answer about keeping in mind the runtime version being used and iterator checking configurations. – Michael Burr Jun 09 '11 at 14:26
2

I would prefer an alternate solution (that requires less work). If you can't find one, this could work for you:

  • Move the long-executing input handling code to a separate library project
  • Build the library as non-debug
  • Link the library into your main project
  • Compile your main project as debug
Merlyn Morgan-Graham
  • 58,163
  • 16
  • 128
  • 183