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

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

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.

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?

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 = from;
}
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.

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.

I tried turning off Edit & Continue, but it had no effect on runtime performance. Memory shouldn't be a problem for me; my PF usage is approximately 600 mb and I have 1.5 gigs of ram.

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.

I tried all of that, didn't make a difference.

[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]

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

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?

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.

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)

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 :)

It's my understanding that, if a property is simple enough, the JIT will inline it and perform optimizations on the inlined code.

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.

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

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.

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.