Paul Liebrand’s Weblog

Welcome to my blog mainly about SharePoint

SharePoint Development to BIN folder and extremely slow initial render times – Solution!

My fellow co-workers and I have been dealing with an extremely slow build > render process when we are developing SharePoint solutions that are deployed to the BIN folder for over a year now.

We are all using are own Windows Server 2003 image hosted on a VMware ESX Server farm with tons of other VM’s.

We all know that SharePoint can take anywhere from 30 seconds to 2 minutes to fire up the very first time you hit it and we accept that fact. However, we found ourselves waiting for up to 1 minute after making some code changes and perform a build that deployed the DLL to the BIN folder for SharePoint to render.

This can become extremely frustrating and frankly a waste of our time. I had gotten to a point where I just accepted the fact we had to deal with the slowness because no amount of tweaking we did on the VM (adding memory, CPU, etc) seemed to make a difference.

One of my co-workers did not want to accept the fact continued to investigate/troubleshoot the issue. He happened to come across the Understanding ASP.NET Dynamic Compilation ( article, more specifically the section called Optimizing Dynamic Compilation. This section mentions an attribute you can add to your web.config file called optimizeCompilations which requires you to install a hot fix (KB961884). This attribute is going to be part of the .NET Framework 4.0 when it ships.

We were all amazed at the difference this attribute made to our development process. In one instance, it cut the time from 1 minute 10 seconds to 12 seconds (80% improvement!!).

The following screenshot shows the change in time with the attribute set to false and then set to true (fairly vanilla SharePoint application). The WebTimer utility just makes a simple web request to my SharePoint site.


Here is the order events described above:

  1. optimzedCompilations attribute in web.config was set to “false”
  2. Performed IISRESET to baseline
  3. Executed WebTimer (40 seconds)
  4. Modified some code in my solution and performed a build (which went into the BIN folder)
  5. Executed WebTimer (30 seconds)
  6. Switched optimizedCompilations to “true”
  7. Performed IISRESET to baseline
  8. Executed WebTimer (40 seconds)
  9. Modified some code in my solution and performed a build
  10. Executed WebTimer (12 seconds)

Needless to say, we have happy developers again! 

You may or may not see much advantage to this if you are developing on a physical machine or on a workstation edition of a virtual client (VPC, VMware Workstation, or Virtual Box). But if you are running in an environment where the resources are being shared or you feel your build to render process seems slower than it should be, I highly recommend you try this hot fix / attribute out.


September 18, 2009 - Posted by | SharePoint | , ,


  1. Wow, great stuff. Will check this out for sure.

    If you are dealing with slow spin up times then you may also want to check out the article we wrote on the subject.

    Comment by Jeroen Ritmeijer | September 18, 2009

    • Jeroen,

      Good point! I forgot to mention that we did implement the certificate revocation solution a few weeks ago (attempting to solve our slowness) and this also cut some time off our initial render times dramatically.

      We found doing the certificate revocation and the above satisfied our frustration levels.

      Thanks for reminding me about that!

      Paul Liebrand

      Comment by Paul Liebrand | September 18, 2009

Sorry, the comment form is closed at this time.

%d bloggers like this: