Sign in to follow this  
RobKo

[.net] Slow debugging in VS2005 (C#)

Recommended Posts

Performance drops dramatically for me in VS2005, if I run something in debug-mode. It does not matter, if I compiled a debug version or a release version, just clicking "start debugging" instead of "start without debugging" makes things slow. I found out, that all of my performance problems are related to System.Drawing.Bitmap - it might be a new debugging option concerning interop, but I did not find it. An example: namespace ConsoleApplication1 { class Program { static void Main(string[] args) { System.Drawing.Bitmap b = new System.Drawing.Bitmap(1000, 1000); int bla = 0; for (int x = 0; x < 1000000; ++x) bla = bla + b.Width; } } } This takes not even a second when I "start without debugging". It's as fast in VS2003, either with or without debugging. But it takes 10 seconds with debugging in VS2005. I could actually bypass all debugging performance problems but one: Loading a single texture with managed DirectX (for .Net 1), using a Bitmap object takes half a minute. Any hints? Could somebody test, if this problem is common?

Share this post


Link to post
Share on other sites
RobKo, I haven't messed with the release of VS2005 yet personally but from what I hear its suppose to be just as fast as VS2003. I had a similar problem to yours before using VS2003 though. What had happened was I ran one of those "XP speed tuner" applications. I'm not sure what it actually did to my computer that caused the problem but when I went to my restore point it was fixed. I think it had something to do with "disabling dr. watson" actuallly but I can't be sure on this.

-Kyle

Share this post


Link to post
Share on other sites
I also noticed a significant decrease in runtime performance, though not quite as significant as you describe. My FPS drops from about 300 in "start without debugging" to about 150 in "start debugging", and the load time of my app is about twice as long.

Share this post


Link to post
Share on other sites
I have a problem where using Texture.FromBitmap, with a bitmap in assembly ressource is horribly slow (ie, one call takes 5-6 seconds). I am using MDX (October 2005 Update, 1.1 version), on 2.0 Framework runtime. Perhaps there are some similarities with your problem. Anybody else got something similar? Any advice?

Share this post


Link to post
Share on other sites
I ran my little ConsoleApplication1-Test on another computer - same behavior.

To load the textures, I'm now doing something like:

texture = new Texture(device, bitmap.Width, bitmap.Height, 1, Usage.Dynamic, Format.A8R8G8B8, Pool.Default);
Microsoft.DirectX.GraphicsStream a = texture.LockRectangle(0, LockFlags.None);
System.Drawing.Imaging.BitmapData bd = bitmapitmap.LockBits(new System.Drawing.Rectangle(0, 0, bitmap.Width, bitmap.Height), System.Drawing.Imaging.ImageLockMode.ReadOnly, System.Drawing.Imaging.PixelFormat.Format32bppArgb);
unsafe
{
uint* to = (uint*) a.InternalDataPointer;
uint* from = (uint*) bd.Scan0.ToPointer();
for (int i = 0; i < bd.Height * bd.Width; ++i) to[i] = from[i];
}
texture.UnlockRectangle(0);
bitmap.UnlockBits(bd);

Always fast, but doesn't work with every bitmap. I hope, Managed DX for .Net 2 will do something like this itself, Managed DX for .Net 1 is probably using bitmap.GetPixel.

Share this post


Link to post
Share on other sites
Try turning off edit and continue. (It's a debugger option) It is slow and buggy.

Also, VS.Net is a natorious memory pig, but this can be mitigated by doing the following:
Turn off unused IDE features and close down unused IDE windows.

Share this post


Link to post
Share on other sites
Make sure you've not got 'mixed mode debugging', and only managed mode debugging?

We've got a large C++ project, that when we hook into ONE c# component the following happens.

1. MSdev takes 20 seconds+ to load the .shed (i mean, .net) runtime
2. Then each debug line takes 5-10 seconds to step-over.
Release builds are fine however.


Share this post


Link to post
Share on other sites
[crosspost from MSDN forums and MDX newsgroup]

I spent a little time looking at this. Tom indicated to me that the MDX code hasn't changed so it had to be a change in .Net 2.0. He also told me that the from bitmap code uses bitmap.GetPixel to be an generic as possible and deal with all formats of bitmap.

Comparing the perf of GetPixel between 1.1 and 2.0 gives a 20x decrease in speed whcih nicely explains the MDX decrease.

So comparing GetPixel in 1.1 with 2.0 with reflector the only difference is that 2.0 range checks X&Y before interoping into GDI. 4 comparisons didn't seem too harsh to me, but it compares against .Width and .Height which are interop functions themselves. So each call to GetPIxel has 2 extra interop calls to GDI and 4 comparisons.

So there is no easy work around other than rolling your own. You should be able to match the 2003 perf and still cover all the bitmap functions by writing your own that interops into GDI.

(As pointed out by RobKo, the issue wasn't release vs debug, but run with/without debugging so removing the next paragraph)
I didn't notice any increase in speed when compiling in release mode on my performance test, which makes sense. In the reported cases it must have been a speed up in the rest of your code rather than a speed up in the perf of texture loading.

I don't know if the DX team will be speeding this up in future releases, but it looks like a good area for perf increases.

[Edited by - thezbuffer on November 25, 2005 6:34:06 PM]

Share this post


Link to post
Share on other sites
...and the reason the code in the first post speeded up so much in release vs debug is probably that the compiler moved the constant b.width outside the loop.

Share this post


Link to post
Share on other sites
It is not release vs debug. It's "Start Debugging" vs "Start without Debugging". And how could it even know, that bitmap.Width is a constant?
My MSDN posts are there -> http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=138755&SiteID=1
Where are yours?

Share this post


Link to post
Share on other sites
Becuase its a property thats not marked as volatile so its not going to change inside a loop so the compiler sees it as a valid optimisation and makes the property call once. However I didn't look at the IL so it was just an educated guess.

Point taken on the debug vs release, I did indeed read that wrong and I will go back and re run my test code.

My MSDN post is sitting in notepad at the moment becuase MSDN forums 'has a problem posting' and 'the error has been logged'.

And I'm not sure why the agressive tone, I'm really just trying to help. There's hundreds of posts in MSDN and the newsgroups (Under Zman - alias not availalbe on gamedev) from me though maybe not in that thread.

Share this post


Link to post
Share on other sites
So much as I hate replying to my own replies, I wanted to say I re read *this* thread properly now (rather than the ones on news and MSDN which were originally talking about the MDX texture load problem) and see what Rob is talking about regarding slow debugging. And to go full circle, I repro, and don't have an explanation since its obviously not the extra interop or bounds checking.

I would suggest a post in the debugger forum at MSDN
http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=56&SiteID=1

(I typed a summary post but I'm still getting errors posting on MSDN)



Share this post


Link to post
Share on other sites
I didn't want to sound aggressive, I never do. Sorry about that, but English is not my native language, I'm probably not very good at getting the right tone. I'm a regular visitor of the ZBuffer and when I wrote my first post I actually hoped you'd help me out.
I still don't understand the property thing though. AFAIK properties are just syntactic sugar for methods and the C# spec does not mention volatile for properties.
I'll have a look at the debugger forum now :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Holy Fuzz
It's my understanding that, if a property is simple enough, the JIT will inline it and perform optimizations on the inlined code.


Sure, function inlining. But Bitmap.Width does some interop, it would have to know that the interop call returns a constant.

Share this post


Link to post
Share on other sites
I'm happy to be wrong on the compiler assumptions, it seems I took the thread off on the wrong track anyway. Sorry all.

The original perf issue has bounced around in the MSDN Forums
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=138755&SiteID=1
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=147513&SiteID=1
and it was suggested that RobKo entered it as a bug.

If you want to add your vote to the bug, or just follow along this is the link

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I HAD THE SAME PROBLEM............

BUT I FOUND THE SOLUTION TO MY PROBLEM...............

REMOVE EVERYTHING FROM THE WATCH WINDOW..................

WHEN WE KEEP ADDING VARIABLES OR EXPRESSION IN WATCH WINDOW THEY HAPPEN TO STAY THERE FOREVER................

DELETE THESE VARIABLES AND EXPRESSIONS FROM YOUR WATCH WINDOW..........

HOPER THIS HELPS ALLLLLLLLLLLL

REGARDS,

Atul Kiraplani

Share this post


Link to post
Share on other sites
I had this problem too (though it also affected me in Release mode). The Width and Height properties are incredibly slow on a Bitmap, for starters.

My solution was to create a temporary MemoryStream and .Save() the Bitmap into it. Seek() to the start of the stream then load the texture via LoadFromStream() instead.

Share this post


Link to post
Share on other sites
The issue appears to be the MS Debugging Assistant which does the on-the-fly CLR code modifications which add debugging power but can kill performance. Check out the MSDEV 2005 product feedback entry that explains the issue (the post discusses the MDA problem in the context of C++ std::string, but the issue is common across managed and unmanaged code):.

http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=e976ea2a-ba1e-4537-9493-46af9429a81e

The quickest workaround for me was to set COMPLUS_MDA to 0 in the env vars - I set it and restarted Dev Studio and Walla! it was working as fast as it used to in 2003! You can also control this setting from the registry, and you can also do it per application using a config file (probably the best way). You'll find the details on how to disable the MDA here:

http://msdn2.microsoft.com/en-us/library/d21c150d(en-US,VS.80).aspx

I hope this spares some of you out there debugging agony like it did for me - I was having too many coffee cups after hitting F5 :)

As you can see from the product feedback correspondence, MS was aware of this issue since Beta.

Note that VS 2008 has the same issue.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this