Archive for April, 2010

Visual Studio Build Time Cut By 85%

If you’re an ASP.Net Developer reading this post, you’re probably frustrated with the amount of time it takes to build and launch an ASP.Net web page, especially when working with complex multi-project solutions.  The interesting thing is the majority of the wait time is post-build, while the web server (either .Net Dev Server or IIS) recompiles the code for every page on your site.  In order to pinpoint the hardware bottleneck, I opened an instance of Resource Monitor while compiling and running one of my larger web solutions.  Interestingly, the major bottleneck appeared to be the Disk I/O.  Note that your CPU can also bottleneck the process, but the Hard Disk is the number 1 culprit causing the slow compilation.

Using the solutions below, I was able to cut the build time on my current project down from over 1 minute to about 7 seconds.  Here are the two solutions I’ve found to the problem.


Solution #1
The first successful solution was to install a Solid State Hard Drive.   Solid state drives use flash memory to store data, which provides sub-millisecond access times when locating files.  ASP.Net compilation involves intense I/O of small files, which is the #1 strength of solid state drives.  After much research, I’ve found the Intel X25-M to currently be the clear winner in terms of price/performance for solid state hard drives.   I bought mine at $500, but you can now get one for less than $250.  Newegg usually has the best price on these:

Intel X25-M Mainstream SSDSA2M080G2XXX 2.5″ MLC Internal Solid State Drive (SSD)

This not only greatly improved build times, but also made all of my apps snappy. Photoshop loads up instantly now, instead of the annoying 10 second delay.   Note the 80Gb storage capacity is a limitation, so you’d probably need a secondary storage drive. Also, solid state drives are great for laptops, b/c they aren’t sensitive to shock like traditional hard drives.

Solution #2 (The Even Faster and Free Solution)
If you’ve got a lot of RAM, create a 500Mb NTFS RAM Drive, and direct Visual Studio to use it as the temp directory.  99% of that file I/O is in the temp directory, so this is a free way to instantly speed up your builds.

If you created your RamDrive as R:\, just adjust the web.config as follows:
<compilation tempDirectory=”R:\” debug=”false” />

Here’s the free RamDrive software I use.   It’s shareware, so it has an annoying popup in the taskbar unless you register it (There is no popup in Windows 7 however).   There are 2 downloads you need.
http://www.ramdisk.tk/

I’m currently the only developer in our company.   There’s no way I would’ve been able to keep up with the workload if I was still dealing with that +1 minute build time.  I Hope you can use these tips to save yourself and your organization a boatload of time.

Please leave any other tips for improving build times in the comments section below.  Thanks!

.Net Framework 4.0 Update Panel Problems

For those of us who use the __doPostBack method in combination with hidden fields to control updatepanel post backs, the latest .Net 4.0 release presents a small problem.   __doPostBack calls without an associated control id no longer cause a full postback when executed from an updatepanel.  Somehow, .Net knows which update panel you execute the __doPostBack call from and in response only updates the associated panel.   Click here for more information on launching post backs directly using JavaScript.

This poses a problem if you have written code that actually needs to launch a full page postback from within an updatepanel.   The work around is pretty simple, though it’s quite annoying to browse through a multi-project solution and find every instance of this issue.


Workaround:

Whenever you want to launch a full page postback using the __dopostback command, you’ll need to include a matching hidden field outside of all update panels.  Here’s a sample:

<asp:UpdatePanel ID=”up1″ runat=”server”>
<ContentTemplate>
<input type=”button” onclick=”__doPostBack(‘cmdDoSomething’, ”);”>
</ContentTemplate>
</asp:UpdatePanel>

<!– Force Full Page Postback Here –>
<input type=”hidden” id=”cmdDoSomething” >

I’m very thankful for FireBug, as I spent about 5 hours using it to track down and resolve this issue.  I’d love to hear from anyone who may know more about underlying changes to AJAX functionality in the new 4.0 Framework.  I’m concerned that there may be other hidden problems arising as I convert more sites over to 4.0.

Return top

__doPostBack Site Info

A discussion of ASP.Net Ajax design patterns and best practices.