0

I have been struggling with performance issues for quite a while, and I have recently realized that the performance I obtain when running from visual studio don't mean anything.

What surprises me much, though, is that I have very different performances depending on how I debug: When I run my program from visual studio, even in release mode, it is more than 10 times slower than when I run my program directly and then attach it to the visual studio debugger. Do you know where this difference comes from ?

Ernest_Galbrun
  • 2,514
  • 3
  • 21
  • 33
  • 6
    Running performance tests with a debugger is absurd, no matter how you start the debugging session. Debug the program, once it works build in release mode and measure performance **without** interference from a debugger – David Rodríguez - dribeas Jun 19 '13 at 14:38
  • 1
    @DavidRodríguez-dribeas: Not really. If you're using instrumenting profiler, debug build will give you better line-by-line information than release build. – SigTerm Jun 19 '13 at 15:31
  • @SigTerm: at any rate (I won't enter the discussion of whether building debug or release with symbols), running inside the debugger will incur extra costs that will make the performance measurements incorrect [Note: not saying that you cannot get profiling information (% of time spent in different parts), just that it won't be the real picture and it will not be **performance** information] – David Rodríguez - dribeas Jun 19 '13 at 15:36

2 Answers2

2

Visual inserts plenty of tests into your executable at runtime when you run it into the debugger:

  • Heap corruption checks
  • Stack corruption checks
  • Mem leaks checks
  • some even more subtle, especially if you run CRT

It does so by inserting a custom memory allocator library that supersedes the standard one. All your calls to new, delete and all your stack operations (entering/exiting a function) are watched...

So yeah, for performance analysis, don't run into the VS debugger.

If you want to unroll what's happening in your code, you can take a look at the answer here:
Is there a good Valgrind substitute for Windows?

Especially the second answer that has interesting pointers. One of the tools suggested is very useful: http://www.codersnotes.com/sleepy

Community
  • 1
  • 1
Gui13
  • 12,993
  • 17
  • 57
  • 104
1

Even if you build in release mode, the default run mode in VS is to attach the debugger (which is always slower because it inserts a bunch of checks and monitoring). If you want to test a 'normal' run from within VS, use 'Debug>Start Without Debugging' or Ctrl-F5.

Sogger
  • 15,962
  • 6
  • 43
  • 40