Launching VS Profiler boosts Application Performance x20?

EDIT 1

I do not exclude at all this might be caused by something very basic side effect of using the Profiler (some faulty setting in my "regular" project)

I wanted to improve Computing Time in my Application, so I decided to go through a thorough profiling analysis. So I just launched a .Net Memory Allocation Profiling to analyze my App.

I was completely stunned to watch computing go x20 times faster !

Application consists of Reading Data from Binary Files with BackgroundWorkers, process them,

and store results into an MSSQL DB. Each round usually takes 20 seconds, and while profiling it barely takes 1 sec. I checked and made sure results are coherent in both cases.

A .Net experimented friend told me the profiler optimizes threading and "somehow" finds its way through thread Locks and Bottlenecks, but I just can't believe it.

So my questions are :

1. WHAT EXACTLY HAPPENS, HOW, and WHY ?
2. How to make my code behave like that natively ?

EDIT 2

I KNOW this sounds crazy and unbelievable. I myself am still very suspicious.But it's TRUE.

The SAME code runs really fast when run by the profiler. I use the SAME test data, and watch the SAME computing output. I am not able to give out a simple reproducing project, as it is a relatively big framework. I am using the Visual Studio 2010 Profiler.

I'll be giving as much details as I can on the flow and definitely will post a clue as开发者_如何学JAVA 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..

Profiler Run LOGS :

03/24/2011 11:38:15 | 113815.592 | SIMULATING SET [5]-[1]-[5 PC-1 0 [SET 1/48]

03/24/2011 11:38:17 | 113817.350 | PROCESSING TIME : 00:00:01.7581005

etc..

EDIT 3 : The Clue

Ok ok ok My BAD(I warned on such a possibility on edit 1, as this was too unbelievable. Sorry) @Watts suggested to check if I was in debug or release mode. Which I had Already done. BUT @SnowBear pointed out that there are two different things : to run debug version of software and to run a software under debugger I made sure that the active configuration was RELEASE in both Build And Execution is VS2010. However, as I was just going nuts I decided to launch the Application directly from the exe file in the bin/release. And voilà... processes were taking 1 second each. Running the Profiler get you out of debug mode (whether you're in release or debug mode) that's what put me into confusion.

Thanks to All Case Closed.

Running with the debugger disables jit optimizations. If you run the exe normally jit optimizations will be enabled. Attaching a debugger to such a running application allows you to debug it with enabled optimizations.

Release-Build vs Debug-Build has two consequences:

1. A conditional compiler symbol is (un)defined
2. It enables/disables optimizations in the C# => IL compilation.

I've come across this many times... There is a very simple explanation for it. The profiler doesn't dispose objects, so the cost of object-disposal is not incurred while profiling.

Thus, if you want to improve performance to make it match the profiled performance, figure out where you're instantiating all these short-lived objects, and refactor the code.

I don't yet know of a really great way to immediately find the offending code, but I can help you narrow it down. If you profile your code, open the report, select "Functions" as your Current View, and then sort by Inclusive Samples, you will see the top methods... Your performance problem with object-instantiations is likely to be in one of those methods with the most Inclusive Samples.

If you are using threads within your code, the windows timer resolution is also a reason for this.

Default windows timer resolution is 15.6ms

When you run your application with the profiler, this is set to 1ms and the application runs faster. Checkout this answer

I do not know exactly why this is happening. I would be tempted to say that only Microsoft knows, but actually, I doubt even that. However, I can tell you one possible fix:

Go to the "Debug" tab of your project properties and make sure that "Enable unmanaged code debugging" is unchecked.