7

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 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.

Josh M.
  • 26,437
  • 24
  • 119
  • 200
Mehdi LAMRANI
  • 11,289
  • 14
  • 88
  • 130
  • 1
    Downvoting whithout any comment is not very convenient – Mehdi LAMRANI Mar 24 '11 at 11:17
  • 2
    I don't believe it. The point of profilers is not that they make your application faster just by running them. You have to actually apply what you learn from running them to optimize your code. **If you want anyone to take you seriously, post a small repro project and the name of the profiler you're using.** (Not my downvote; I'll hold out to see if you can substantiate this.) – Cody Gray - on strike Mar 24 '11 at 11:23
  • @Spence : I've really got better things to do in my life – Mehdi LAMRANI Mar 24 '11 at 11:36
  • 1
    Are you sure that you're not running the application in release mode under the profiler, and in debug mode under the IDE ? – Miki Watts Mar 24 '11 at 11:40
  • I had this doubt, but I made sure that both are run in release mode. But i do not exclude this might be something stupid like that. – Mehdi LAMRANI Mar 24 '11 at 11:45
  • "I'll be giving as much details as I can" the name of the profiler and a link to a downloadable sample project would be a start. I'm with @Spence. – BenCr Mar 24 '11 at 11:47
  • How do You want me to give a downloadable sample project of proprietary software I do not even own ???? And what is the "name" of the profiler ? What do you mean ??? It's VS2010's Profiler ".Net Memory Allocation ???* – Mehdi LAMRANI Mar 24 '11 at 11:50
  • @Watts you were right !!!!! I will edit to explain – Mehdi LAMRANI Mar 24 '11 at 11:56
  • 2
    @Mika, regarding your last edit. There are two different things - to run **debug version** of software and to run a software **under debugger** – Snowbear Mar 24 '11 at 12:12
  • @Snowbear: I was not aware of that at all... Sorry... So running the profiler quits the debugger. And running the release version under debugger cuases drastic slowdown. Well. At least I would have learned something today. Thank you. And I apologize for my ignorance. – Mehdi LAMRANI Mar 24 '11 at 12:24
  • @Mika: I just checked back in to see if you'd updated the question with some more details. I very much appreciate your doing so, and I'm sorry people were rude to you along the way. There's absolutely no need to apologize for your ignorance. It's a common misunderstanding that pressing F5 in Visual Studio will attach the debugger, even to an app compiled in "Release" mode. It's best to do all profiling/benchmarking from *outside* of the IDE, or at least start without the debugger attached (generally Ctrl+F5). I'm glad you learned something; that's really why we're all here in the first place! – Cody Gray - on strike Mar 24 '11 at 13:04
  • @Cody : Thank you that's Nice of you. Good Spirit (I was beginning to feel a bit uncomfortable with arrogance and lack of understanding.) – Mehdi LAMRANI Mar 24 '11 at 13:50

4 Answers4

5

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.
CodesInChaos
  • 106,488
  • 23
  • 218
  • 262
0

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.

Mike Nakis
  • 56,297
  • 11
  • 110
  • 142
0

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.

ZipXap
  • 71
  • 1
  • 1
0

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

Kusal Dissanayake
  • 714
  • 14
  • 32