[.net] Slow debugging in VS2005 (C#)
Author
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?
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
-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?
Author
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.
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.
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.
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.
[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]
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]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
