Hello,
I've noticed that when I'm debugging MDX1.1 applications in VS2005, they achieve a significantly lower framerate than when debugging them in VS2003. The performance decrease differs per application and seems to be somehow linked to the use of HLSL effects, as applications that use the Fixed Function Pipeline do not suffer this decrease.
This morning I witnessed an extreme case of this problem with a little game that renders multiple meshes using HLSL effects. It achieved a lowly 60fps when I ran it in debug from VS2005, whereas it achieves a 550fps framerate when I just run the debug exe from Windows Explorer (both using the DirectX retail runtime).
This problem can be easily reproduced by debugging the BasicHLSL sample (yes, the MDX1.1 one) from the SDK in Visual Studio 2003 and 2005. On my ATI Radeon X850, the sample achieves a framerate of about 1000fps when debugging in VS 2003. When I debug it in VS2005 Team Suite, it only achieves a framerate of 600fps. The decrease is also there when I run the prebuild debug exe from VS2003 in VS2005.
So, what am I missing here 
Degraded performance when debugging MDX1.1 applications in VS2005 compared to VS2003
Brian Sullivan
Do you have any further information on this issue I've had to switch to Visual Studio 2003 for a small game demo using MDX1.1 (source available here) recently because the framerates I got in VS2005 were inexplicably low. It may even have been an issue with the .NET 2.0 debug build, since running the compiled executable outside of VS2005 gave somewhat higher, but still unexcpectedly low framerates.
Anyway, by adding my source code to a VS2003 project manually and recompiling that, the framerate more than doubled (from about 150 to 350 fps) without any changes to the code whatsoever. Another unrelated project seems to work just fine in VS2005 though. I have also received mail through mdxinfo enquiring after this, so any further information would be much appreciated.
HugoLeiva
Yeah, ok... the fact that you can count on the app actually performing significantly better when you run it outside of VS2005 could actually be called a nice feature, but still...
The strange performance difference between MDX on either .NET1.1 or .NET2.0 is an entirely different matter though, so it might also be worth looking into. I don't know if this should go into the newsgroups or if I should just post it here, so my apologies if this is the wrong place to ask.
I have run some tests on the performance of two MDX1.1 applications, built in both VS2003 and VS2005 (so essentially against .NET1.1 and .NET2.0, just to be sure) and executed as stand-alone programs from Windows Explorer (so no VS2005 debugging issues here). My first guess that the SampleFramework might have something to do with it turned out to be wrong, as the performance for the EmptyProject is the same on both platforms:
EmptyProject sample
_________________________________
VS2003 Debug 293 fps
VS2005 Debug 293 fps
VS2003 Release 295 fps
VS2005 Release 295 fps
My BrainBall demo however does suffer from a strange performance drop when compiled in VS2005. I have created a new sample version of the demo with both a VS2003 and 2005 project file. Each test executable was rebuilt from the exact same code on both platforms. The results are indeed rather puzzling and a bit alarming, as they show less than half the performance for MDX1.1 on .NET2.0 compared to .NET1.1 (also when expressing performance in frametime instead of FPS):
BrainBall demo
_________________________________
VS2003 Debug 865 fps
VS2005 Debug 350 fps
VS2003 Release 868 fps
VS2005 Release 350 fps
The test executables and the source for the demo project can be found in the archive linked below. Tests have shown that this problem can be reproduced with the BrainBall demo exe's on my system every single time.
http://www.mdxinfo.com/temp/DotNetPerformance.zip (1MB ZIP)
Any ideas
milfora
No you were clear - well back when the thread started you were, my memory apparantly is not so clear.
Yes this is puzzling. I thought .Net 2.0 was supposed to make most things faster. I guess the only way to sort it out is with profiling which I'm sure none of us have time to do any time soon.
CWeeks
RobD
I got the same answer about performance issues with VS2005 in debug mode when I posted in the beta MDX2.0 newsgroup.
One benefit is that it helps you tune your code as you program...
VS228
Who knows - maybe the MDX 2.0 bits were non optimised debug builds. Now that MDX 2.0 is never going to release as is we may never actually find out.
We can start benchmarking XNA framework instead when it arrives.
very saggy
The only 'known' bug with VS that I am aware of is the MDA/Interop one which makes Texture.FromBitmap mind bogglingly slow since MDX interops through many bitmap.getpixel calls. So generally this affects startup.
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx feedbackid=0dda86da-a83f-475d-8610-d3a08a14cc7f (passport needed)
http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=147513&SiteID=1
http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=138755&SiteID=1
If you do ctrl-f5 (start without debugging) you can see if the debugger is causing the slowdown or not.
I've had at least one email claiming that MDX under .Net 2.0 was slower but the poster appeared not to have any serious evidence and I didn't have time to benchmark anything.
Now FAQ'd http://www.thezbuffer.com/articles/401.aspx
sabreman
Sorry, I should have been a bit clearer about this. The above problem deals with compiling the same (or rather comparable) MDX1.1 application in both VS2003 and VS2005, essentially against the .NET1.1 and .NET2.0 platforms.
The later version of this demo compiled against the .NET1.1 framework does a whole lot more and still achieves a higher framerate than a more basic version compiled against the .NET2.0 framework. Puzzling, no
Patrick Bristow
I don't have two exactly identical projects for both the .NET1.1 and .NET2.0 version around any more, but I'm fairly certain that this isn't the debugging issue I had earlier. I have a backup of the project compiled against .NET2.0 that renders a ball in HLSL at ~330 fps (~115 fps when debugging in VS2005).
A later version of the demo compiled against .NET1.1 uses the exact same code and shader for rendering the ball and it manages to do this and render approximately 150 additional meshes at ~430 fps. The code was .NET1.1 compatible anyway, so this allowed me to just reuse the exact same code (I use the refactoring features of VS2005 a lot, so that's why I used that initially).
All fps measurements were taken about 5 seconds into the program, by simply estimating the average fps displayed by the SDK SampleFramework I used for this project, so it isn't just a startup issue ... Could the SampleFramework perhaps be causing this performance drop This certainly would explain why I don't have this issue with the other project in .NET2.0 I'm working on, as that's coded from scratch.