Visual Studio Performance with Slow Laptop Drives

As Scott Guthrie wrote, hard drive speed makes a big difference to the performance of Visual Studio.

So what can you do if, like me, you are using a laptop and so can't upgrade to a faster hard-drive? I've found two things that have helped a lot. In one test case they reduced my build time from 28 seconds down to 3 seconds(*).

Step 1: Avoid slow virus scanners

This made the biggest difference of all. As Jeff Atwood reports, some real-time anti-virus scanners can slow your machine down drastically. My test build dropped from 28 seconds to 7 seconds when I turned off my virus scanner! That seems entirely consistent with the results that Jeff has summarised on his page. In fact, judging by his post, it appears that some products may be even worse.

For the record, I was using TrendMicro OfficeScan. I don't know why it had such a large adverse impact. Googling the vendor's website failed to unearth anything relevant, but I've heard anecdotal evidence of it reading all bytes in a file when Visual Studio merely wants to check the timestamp. On the other hand, my colleague on the next desk uses the same product (on faster disk hardware) and says it's OK.

[Update: I've switched to AVG and it's looking good - much, much faster. I'm also trialing NOD32 on another machine, because I've read good things about it.]

Step 2: Use disk caching (with lots of RAM)

I've upgraded to a total of 4GB RAM in my laptop. Since I'm running Windows XP, the operating system only sees 3-and-a-bit, but that still gives me enough to run an in-memory disk cache.

I'm using eBoostr to run the cache. It seems to be working very well. It reduced my test build from 7 seconds down to 3 seconds, and subjectively it seems to be having a noticable positive influence*.

If you go to the eBoostr site, you'll see that it is advertised as being the XP equivalent of two Vista technologies, ReadyBoost and SuperFetch. Those technologies are about reducing system boot and application start times, but it also turns out to be good at reducing compilation times. That's not suprising really, since it works by caching the files that are most frequently used. Since I'm interested in compile times rather than boot times, I have configured it to do all it's caching in RAM. I don't even plug in a USB device.

In a typical day's coding its built-in monitoring tool reports average cache hit ratios of around 80 or 90%, which means it's allowing the machine to skip a lot of disk access.

I definetely recommend giving eBoostr a try. The cost is very competitive and it has very generous evaluation terms - you can use the eval copy for ever, with the only limitation being that it turns itself off 4 hours after every reboot. This means you can take your time evaluating it, as long as you don't mind rebooting daily.

My only criticism would be that the documentation doesn't really explain how it decides which files to cache. I emailed the vendor about that point, and they sent a very informative reply, which I'll summarise in a future post [here].

One word of advice: if you run Visual Studio and a local copy of SQL Server (as I do), don't bother with RAM caching if you only have 2GB of RAM. Get more RAM first, then start caching. I'm using a cache size of about 800MB, which seems large enough to be useful, and small enough to leave enough RAM for all my dev tools.

Finally...

(*) Your mileage may vary - and in fact my mileage does too, depending on what I'm doing and (presumably) on what is in the cache at the time. In some of my tests, the virus scanner seems to account for all the difference; with little difference coming from the cache. In other tests, the cache makes a noticable difference.

In any case, I'm enjoying TDD again. The 30-second builds used to break my chain of thought, but now the edit-compile-test cycle is short enough that it doesn't interrupt my flow. All in all, my 5400 RPM drive no longer feels like a serious problem.