Running VS Profiler improves x20 application performance?

Question

EDIT 1
I do not exclude at all that this may be caused by something very significant side-effect of using Profiler (some erroneous settings in my "normal" project)

I wanted to improve the computing time in my application, so I decided to go through a thorough profiling analysis. So, I just started profiling the .Net memory allocation to analyze my application.
I was completely stunned to watch the calculations x20 times faster !

The application consists of reading data from binary files using BackgroundWorkers, processing them, storing and storing the results in the MSSQL database. Each round usually takes 20 seconds, and when profiling it takes only 1 second. I checked and made sure that the results in both cases are coherent.

An expert .Net friend told me that the profiler optimizes threads and "somehow" finds its way through Locks threads and bottlenecks, but I just can't believe it.

So my questions are:

• WHAT EXACTLY WILL HAPPEN, HOW AND WHY?
• How to make my code behave like this?

EDIT 2
I KNOW , that sounds crazy and incredible. I myself am still very suspicious. But this is TRUE.
The same code works very fast when the profiler starts. I use EXACT test data and watch SUCH EXIT. I cannot give a simple reproduction project, since it is a relatively large structure. I am using Visual Studio 2010 Profiler.

I will tell you as much as possible about the stream and be sure to publish the key as soon as I find it.

Regular RUN logs:
03/23/2011 18:04:34 | 180434.621 | SIMULATING SET [5] - [1] - [5 PC-1 0 [SET 1/48]
03/23/2011 18:05:01 | 180501,271 | PROCESSING TIME: 00: 00: 26.6515244
etc..

Run LOGS profiler:
03/24/2011 11:38:15 | 113815,592 | SIMULATING SET [5] - [1] - [5 PC-1 0 [SET 1/48]
03/04/2011 11:38:17 | 113817.350 | PROCESSING TIME: 00: 00: 01.7581005

etc..

EDIT 3: Key
Ok, OK, my TROUBLE (I warned about this possibility when editing 1, because it was too unbelievable. Sorry) @Watts suggested checking if I was in debug or release mode. What i have already done. BUT @SnowBear pointed out that there are two different things: launch the debug version of the software and run the software under the debugger. I made sure that the active RELEASE configuration in Build and Execution is VS2010. However, since I was just starting out crazy, I decided to start the application directly from the exe file in bin / release. And voila ... the processes took 1 second each. Starting Profiler will bring you into debug mode (regardless of whether you are in debug or debug mode), which is confusing me.
Thanks to the closed case.

Answer 1

Working with the debugger disables jit optimization. If you run exe, jit optimization will usually be enabled. Attaching a debugger to such a running application allows you to debug it with the included optimizations.

Release-Build vs Debug-Build has two consequences:

• Compiler conditional character (un) defined
• It enables / disables optimization in C # => IL compilation.

Answer 2

Given that the question is that the code works faster under the profiler, and that the specific questions are "1. WHAT WILL EXPRESSLY PRECISE, HOW AND WHY?" and 2. How do I get my code to behave the way it was originally? "the accepted answer is incorrect, because it does not contact the profiler at all and does not mention the specific reason for acceleration by 20 times.

What exactly is going on:

On the "Debugging" tab of the project properties, the checkbox "Enable unmanaged code debugging" is checked; this option causes the debugger to be as slow as molasses.

When you start the profiler, it is still the debug version of your program that you are profiling, so the "DEBUG" symbol is defined, and all traces, statements, etc. are enabled, but the debugger is not enabled, so the option "Enable unmanaged debugging code" is not applicable. (JIT optimization is probably enabled during profiling, but this does not even take into account a 2-fold increase in performance, not to mention a 20-fold increase.)

If you want to enjoy this 20-fold boost when debugging code (not just profiling), go to the "Debug" tab of your project properties and make sure that "Enable unmanaged code debugging" is not checked.

PS

The question arises, which is a two-month duplicate of this: How did it happen when I tried the profile of the program and actually works faster than not profiling?

Answer 3

I have met this many times ... This is a very simple explanation. The profiler does not place objects, so the cost of deleting an object does not arise during profiling.

Thus, if you want to improve performance so that it matches profiled performance, find out where you are creating all these short objects and reorganizing your code.

I don't know yet if there is really a great way to find the code right away, but I can help you narrow it down. If you are viewing your code, open the report, select "Functions" as the current view, and then sort by inclusive samples, you will see the best methods ... Your performance problem with object instantiation will probably be in one of these methods with the most inclusive patterns.