<< Typographic reflections | Fun with Wait and Pulse >>

Cheap way of speeding up Visual Studio I/O

by Dmitri January 28, 2009 21:06

Visual Studio loves file I/O. It really, really does, and it cares very little about caching and the like. What this means is that, when you open a solution file, it always reads it from disk. Which means that the speed of operation when generating lots of files (e.g., via T4 transformations) is typically atrocious. The fact that file I/O in VS does not appear to be multithreaded is another hindrance. In short, it’s a mess.

So here’s a stupid solution that I’ve been using for ages with excellent results – make a RAM disk! By sacrificing a small amount of RAM (I give it 128Mb), you can move your whole solution into RAM, where I/O speeds are far greater – noticeably greater when working with Visual Studio.

To get a RAM disk working, I followed advice on this page to the letter, and got it all set up under Vista. Then, when I need to, I simply snapshot my Subversion projects onto the RAM drive and do my work. If the stuff I work on is sensitive, I can even erase the RAM drive after work – committing beforehand, of course.

Be the first to rate this post

Currently 0/5 Stars.
1
2
3
4
5

Tags:

Visual Studio 2010 Beta 1 ScreenshotsI’ve been using Visual Studio since version 5. In those days, I ran it on a computer with 16Mb...ReSharper Extensibility GuideContents Introduction Where to Look for Help Tools of the Trade Project Set-Up (Important!...Better way of adding referencesI have finally found the solution to the ‘Add Reference’ problem for commonly used assem...

Comments

1/29/2009 6:29:05 PM #

Trackback from DotNetKicks.com

Cheap way of speeding up Visual Studio I/O

DotNetKicks.com

2/1/2009 7:50:05 AM #

It's all fun and games until the power goes out.

Laughing

2/1/2009 8:54:40 AM #

So the project size has to be less than 128 MB. Is it practical to load big projects in to this disk?

John Robins

2/1/2009 11:44:39 AM #

It's all fun and games until the power goes out.
Yep, but that's true even in a situation where you just have an unsaved document. Sure, RAM is volatile, but you can easily sync the RAM with a folder on a hard drive, or do a commit to a source control repository. Oh, and there's also things like UPS that can give you time to save your work.
So the project size has to be less than 128 Mb. Is it practical to load big projects in to this disk?
Actually, this is just a number I've chosen based on what the particular RAM Disk software allows me to do. There are other, commercial RAM Disk programs out there that might not have this limitation.

dmitri

2/1/2009 3:51:21 PM #

configurator

2/1/2009 4:10:07 PM #

Well you'd still have to sync them. Is there a way to make a RAM disk work like a cache, i.e. load a certain directory, caching the load time (which is the heavy part of VS) and saving directly to that directory?

Umm, that's exactly what happens (I think). Here's what I do: I have a Subversion repository on a remote computer; I do a checkout onto the RAM drive and then work with that. If I wanted to, I could also set up SyncToy or similar program to cache the solution on the local hard drive. But I don't, because it's unnecessary. Since I have my own repository, I can commit as often as I want.

One thing I want to point out is that the RAM drive program I use is very stable, meaning that I've never had anything go wrong. And since I hardly ever switch off my machine, I almost always have the snapshot of my work in RAM.

Performance-wise, the results are quite dramatic: the typical "Hello World" program compiles a lot faster when running off RAM. It levels off somewhat when you have multi-project solutions (due to dependencies and such), but it is still way faster than having VS work off a hard disk. Oh, and if you work with code generation (e.g., CodeGenUtils, DSL Tools, T4, and such), the difference in speed is quite dramatic.

dmitri

2/1/2009 8:59:36 PM #

Pingback from alvinashcraft.com

Dew Drop - February 1, 2009 | Alvin Ashcraft's Morning Dew

alvinashcraft.com

2/1/2009 10:52:13 PM #

Another reason to be running 64-bit machines. I have actually played with this technique for small read/write "mini databases" and has bench'ed really well. With 64-bit you get over 4 gig RAM without additional costs other than the RAM itself and scenarios likes this with creating RAM disks is actually a real good idea.

Bart Czernicki

2/1/2009 11:10:26 PM #

Actually, from what I know, 64-bit RAM drive emulation is a lot more difficult. I doubt you could find free software for a 64-bit system. Of course, there are inherent advantages to 64-bit (addressable memory), but I would also consider using something like Gigabyte iRAM (is it still being sold?) if you need to use very large solutions.

And, of course, large amounts of RAM can be used for other, equally useful things - such as in-depth static analysis or searching for duplicates within large code bases.

Extra processors also help in this regard.

dmitri

2/2/2009 8:10:35 AM #

Pingback from blog.cwa.me.uk

Reflective Perspective - Chris Alcock » The Morning Brew # 277

blog.cwa.me.uk

2/2/2009 6:07:39 PM #

Well, some of us don't have their own repositories that they can check in to at any time. Or very stable computers - mine at work reboots daily and I don't even know why.

Re 64bits, wow64.exe should be able to run the 32 bit program without problems.

configurator

2/2/2009 6:55:31 PM #

Well, some of us don't have their own repositories that they can check in to at any time. Or very stable computers - mine at work reboots daily and I don't even know why.
That sucks... for a number of reasons. Having to work on an unstable machine is something that I for one find completely unacceptable (just as working on a slow one).
Re 64bits, wow64.exe should be able to run the 32 bit program without problems.
This isn't a user-mode program we're talking about. There's no 'emulation' possible - the driver has to be perfect and take care of all 64-bit nuances. No small feat.

dmitri

2/5/2009 6:42:31 AM #