VS 2005 – Inferior to VS 2003?
I just installed a trial version of Visual Studio 2005 (I had been using the previous version, 2003).
Theoretically, new compilers can provide the following advantages (that are significant to me, anyways):
1) Better interface/tools
2) Faster compiles
3) Smaller compiles
4) Faster code
Item 1 will take a while to evaluate – I’ll use the new compiler for a few weeks and see what I think. But 2-4 are fairly easy to test. I tested all of the following on my current game, which is fairly similar in scope to Bonnie’s Bookstore.
Compile Time (Full Solution Rebuild):
__________Debug_____Release
VS 2003_____:20_________:30
VS 2005_____:26_________:34
Compile size, KB (Release Mode Only)
_________Game_EXE________DLL____Total ____Total (zipped)
VS 2003_______988________340_____1328_______574
VS 2005_____1,016________612_____1628_______717
Code Speed (Release mode - milliseconds to do 30 passes through my main draw loop, EXCLUDING the blit to the video card)
VS 2003___335*
VS 2005___358*
*These are averages of 10 attempts on each version, and there was significant variability between tests, with a range of 287-375 for the VS 2003 version, and 299-396 for the VS 2005 version. Also, I didn’t hand tweak the optimization parameters for VS 2005, but left them as they were imported from my VS 2003 project. Possibly, more tweaking would improve the 2005 results.
All tests on my main dev box, with a dual-core AMD 4600+ CPU.
I’m surprised that the build time got noticeably slower in 2005 – In theory, the new compiler will use both cores for compiles, which should nearly double the compile speed. Perhaps I don’t have the option properly enabled, but I looked for info on it and couldn’t find any way to explicitly enable or test that feature.
Compiled size is another minor drawback. Since my games are built for download, I like to keep the EXE (and accompanying DLL – i.e. MSVCR71.DLL or MSVCR80.DLL) small. This isn’t a huge issue, since, with graphics and sound, the download will likely be in the 13 MB range. Still, it’s a minor consideration, and perhaps more important for those shooting for very small download sizes. (When I did the Active X version of Bonnie’s Bookstore, I was targeting an 800KB initial download, with further data streamed. OTOH, that version used a static version of the C run-time, and given that most of the extra bulk is in the run-time DLL, the issue may not be THAT severe)
Finally, VS 2005 apparently produces slower code than VS 2003, though possibly the results are just due to noise/variability.
Overall, the raw specs of 2005 look inferior to 2003. Still, if the new version enables me to be noticeably more productive, that will dwarf the comparitively small differences in the above metrics. Hopefully I’ll post an update in the future on the interface differences/improvements.
======================
Edit: I just spent a bit more time playing with the various code optimizations in VS 2005, and now I’ve got the performance to where the draw loop executes about 5-6% faster than in VS 2003, at a cost of slowing down the release mode full rebuild from 34 seconds to 50 seconds, and increasing the file size a bit (from 1016 KB to 1048 KB).
June 22nd, 2006 at 1:32 pm
I understand that by using VS 2005, users will be required to install the .NET 2.0 redistributable before they can use your program.
How do this affect your game plan?
Is it a consideration?
Drew
June 22nd, 2006 at 1:47 pm
No – that’s not true if you’re using native code. Probably true if you’re using C#, Visual Basic, or Java#, but I don’t know the details on those languages (I don’t use them…)
June 22nd, 2006 at 5:42 pm
Have you had a change to mess with the profile guilded optimizer yet?
Did it have any major effect if you did?
June 22nd, 2006 at 6:10 pm
Haven’t touched it.
June 23rd, 2006 at 12:51 am
Regarding VC++ & .NET 2.0, IIRC it has to do with the visual studio runtime DLL. It is actually an assembly now. You can no longer just drop the runtime DLL in the app directory. To avoid the .NET requirement, you have to jump through hoops and bundle the runtime as a Merge Module.
Steve Streeting wrote a couple of blog posts about this some time ago:
http://www.stevestreeting.com/?p=181
http://www.stevestreeting.com/?p=183
There was also an MSDN article about it, but I can’t find the link right now. As far as I know this applies to all editions of VC 2005 and not just Express.
June 23rd, 2006 at 9:17 am
you can cut the size of your EXE a little bit by going into your project’s properties, CONFIGURATION PROPERTIES, LINKER, OPTIMIZATION, OPTIMIZE FOR WINDOWS 98 -> set to false
I also use UPX to compress my exe.
http://upx.sf.net
June 23rd, 2006 at 9:21 am
The compile time increased with VS2005, but on the other hand, they added more stuff to analyze and optimize your code. I just wished that intellisense for C++ was as good as the one for C#.
June 23rd, 2006 at 9:42 am
gdmike – If that linked article is correct, it would be quite annoying. i.e. You might need to install MSVCR80.DLL into proper directory within \Windows\System, rather than just dropping it in your game directory. In turn, doing this properly might require you to use the MS Installer instead of Inno Setup, which I currently use. This might cascade into more dependencies and oddness.
The fallback is to link everything statically. The problem for gamemakers like me, using open source, is licensing issues. I use SDL and SDL_Mixer, which, per license, MUST be DLLs. I can compile them with static links to the C-Run time, and I might end up doing that, but at least with VS Net 2003, it was a bit more efficient to link everything dynamically (i.e. the combined size of all needed binaries and DLLs was smaller with dynamic linking).
June 23rd, 2006 at 7:24 pm
We switched over from 2k2 to 2k5 back around the first of the year. For PotBS (including servers and tools) it didn’t make any significant difference in full build build time. It cut the incremental build time substantially by getting rid of the 1-2 second think that the IDE had to do on each of the 35 projects in the solution. Sadly our build times are still around half an hour.
Edit and Continue seems to work better than it did in 2K2. The hang on exit that we used to get 100% of the time in 2K2 is gone. Source control integration is better in 2K5. I haven’t looked at the code size since our multiple gig of data make anything they might have done there largely irrelevant.
You can control the number of processes it tries to build at one time in Tools->Options, Projects and Solutions->Build and Run. It seems to work pretty well to have it set to 3 on my dual proc machine.
Porting to it wasn’t a huge deal, you just have to add several defines to the projects to get rid of deprecation warnings (though eventually it would be better to actually move away from the deprecated stuff.) The new C runtime DLLs are kind of a pain. You have to put a folder in with your EXE instead of just the DLLs. As long as you do that (and get your middleware providers to upgrade so they’re using the same version of the runtime) it seems to work ok.
The biggest thing that drives me crazy about it is intellisense. It used to work once in a while, but now it doesn’t seem to work at all. And while it’s doing its “background” thinking devenv.exe takes up an entire CPU. Windows deals poorly with one app taking an entire CPU, so it often pauses for 0.5 to 1 second at random.
All in all, I don’t think it was worth the upgrade.