Slash your ASP.NET compile/load time without any hard work

Personally, when it starts taking over a minute to compile or load my application, I start throwing things. This was the case early this week and with a bit of work, I managed to cut down things by an order of magnitude (from around 140 seconds down to around 14 seconds) with only software changes.  This is what prompted me to write this post.

There are three things worth improving:

1. Compilation time
2. First load time (ASP.NET)
3. Application speed / database performance

I only want to talk about the first two; the only tip I’ll give you for #3 is to get your hands on a profiler such as dotTrace as it is a real time saver.

Get better hardware (Big impact)

You’ll get the best bang for your buck by upgrading your hard disk, especially if you’re using a single 5400 RPM or 7200 RPM drive (download benchmark software to evaluate your current disk). Our projects are stored on a solid state disk. We currently use Intel X25-M G2, but the RevoDrive x2 looks much faster (basically a RAID-0 array of SSDs) if you have an available PCI-Express x4 slot. If you’re cheap and find the SSDs to be too small, just get two large 7200 RPM drives and put them in RAID-0. Make sure you’ve got a robust backup solution.

Store your temporary IIS files on your fastest disk or a RAM disk

Depending on the amount of RAM you have, it may make sense to use a RAM disk. I use my RAM disk for my temporary internet files and for IIS’s temporary folder (compilation results). I haven’t measured specific performance details but since I have so much free RAM, might as well try use it in creative ways.
To speed up the first load time, you can tell IIS to store its temporary files on your RAM disk (or fastest disk) by changing the following setting in your web.config files:

<compilation ... tempDirectory="q:\temp\iistemp\"> ... </compilation>

You can either change your project files directly, or, if you’ve lazy and have numerous applications running on your development machine (like I do), update the system-wide web.config files. Note that you need to update this for each runtime version of the Framework and, if running a 64-bit machine, for both Framework and Framework64. On my machine, I needed to modify the following files:

   1:  C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Web.config

   2:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\Web.config

   3:  C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\Web.config

   4:  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\Web.config

Trade-off: If you save your RAM disk when shutting down, you’ll notice how much longer it takes to reboot. I can live with that, rebooting only once every couple months.

Review a few magical settings (Most impact)

When an ASP.NET website is loaded for the first time, it pre-compiles all your pages and user controls. Once done, everything runs faster. This is great for production websites, but horrible for your development machine. Why?  When programming, you’re usually only modifying a page or two (or back-end code). You’ll iteratively make a change, compile, launch the website, test, and start over; often dozens of times. A two minute compile/load time (like we had) forces you to lose focus and get distracted. The following setting makes pre-compilation more selective, making the first load time massively faster in development scenarios. On my machine, it cut the first load time from around 74 seconds to 6 seconds.

<compilation ... batch="false"> ...</compilation>

While on the subject of random boolean flags that make your life better, I should mention the following:

<compilation ... optimizeCompilations="true"> ... </compilation>

This flag has a number of gotcha’s that are documented here. I’ve enabled it for now, although my quick tests didn’t show any significant performance improvements compared to the previous one. However, I was probably not testing the right thing.

Restructure your projects

Try multiple solutions

About a year ago, we took 50% of our least used projects and moved them into a secondary solution. We compile that solution only when changing one of these projects, once every couple months. After rebuilding the secondary solution, we copy the *.dll files to a separate folder. Our primary projects reference those pre-generated libraries. I should repeat this process again, but I like having all my projects in one place and splitting them was a pain. However, this is probably the only sustainable way to manage extremely large solutions.

Selectively build the necessary projects

Using Visual Studio’s Configuration Manager, I also created different active solution configurations in my primary solution with only a subset of the projects included in the build.  I can thus swap between configurations depending on my primary task (working on our point of sale instead of FranchiseBlast, for example). This can drastically reduce compilation time, but I don’t use it as often as I should because:

1. I find the user interface slow to refresh (Visual Studio).
2. My dependency tree is complex and going through the list of projects to remove those I don’t want built is a pain.
3. I context-switch a lot and often hit cases where I modify a project and forget that is not included in the build.

A simpler option is to build only the current project (and its dependencies) instead of all projects. Just make sure you don’t accidentally break the build (recompile everything before a commit).

Parallel compilation (Big impact)

Following Scott Hanselman’s post, I setup my project to compile in parallel. I did add a few options to make it easier for me to see errors/warnings without MSBuild’s typical clutter. (I also had a post-build action using NAnt which I set to quiet). This reduced my full rebuild time from 96 seconds down to 16 (after a clean solution). In a typical recompilation, we’re talking roughly 8 seconds instead of around 66.

Title: Parallel Build

Command: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe

Arguments: /m $(SolutionFileName) /v:m /ds /nologo /clp:Summary;Verbosity=minimal

Initial Directory: $(SolutionDir)

Check: Use Output window.

Trade-off: Error messages aren’t nicely presented in the Visual Studio Error List tab and you are not notified when the build is complete.

Other noteworthy attempts

Over time, I’ve tried a few things that didn’t work out. In general, they improved things slightly but I don’t use them on a daily basis due to the tradeoffs.
I tried putting the whole project (source and output folders) onto the RAM disk but its volatility scared me away, regardless of the performance enhancements (Off the top of my head, it was between 25% and 50%). I then tried putting my only project’s bin folders on my RAM disk (by creating symbolic links from my bin folders to my RAM disk). This also had a positive impact on performance, but not significant enough to warrant the kludge (around 25% reduction in compilation time).
I also found a few tips & tricks for larger projects on Stack Overflow. First, I tried putting ‘Copy Local’ to false for all project references. This gave me a 25% reduction in compilation time, but broke my deployment scripts which needed all the files in the bin folder.  Separately, I configured all my projects Output Paths to the same folder, avoiding content duplication on the disk. This also gave me a 25% reduction in compilation time. Oddly enough, moving this folder to my RAM disk did not impact performance.

Summary

I hope this post gave you some ideas on how to improve your compilation speeds and first load times. I didn’t intend to give exact benchmarks, as performance will vary greatly depending on your projects. However, the main lesson learned is that there are dozens of improvements you can make; it’s up to you to try them out and keep what works for you.
The top three time savers for us are:

1. Setting batch=false in the ASP.NET configuration page. (Now ~10 times faster)
2. Parallel compilation for our projects (Now ~8 times faster)
3. Better hardware (Now between 2 and 5 times faster)

Honorable mention goes to splitting your solution files, even though it’s painful and time consuming process to setup.
Do you have any other tips & tricks you’d like to share with us?

the post was originally published here