2

I recently queried the former Lead Developer at my current place of employment as to why he chose to use the Razor Generator to pre-compile our views in to a separate assembly.

He made some claims below, but I can't seem to find any Razor Generator profiles and/or metrics on the web to back up the claim (10-100 times faster), and/or, if what IIS7/ASP.NET does behind the scenes regarding pre-compiled vs. runtime-compiled views and their benefit or the lack-there-of.

Can anyone point me in the right direction? Or comment?

It seems to me (as far as startup time is concerned) simply setting IIS autostart = true for the site would balance out any benefit of pre-compiling using the Razor Generator. Here is his statement:

Why are we using the Razor Generator to pre-compile our views and why put them in a separate assembly?

The first is simple, compile-time error checking. With this many views it seemed like a great way to avoid errors on production. It's a bit frustrating having to recompile to see the changes to the views I admit, but it is (in my opinion) totally worth it to know that you have that much more error checking upfront.

The second is that when the views aren't compiled in a project they get compiled at runtime and then those compiled representations have to be stored in ram. Sometimes, if they're not accessed regularly (which is the case with most of those views since there are so many) those stored compiled versions get abandoned and garbage collected to save ram. So all but the most frequently accessed views in a site like gaf.com end up being recompiled every time they are accessed. But if you put them in a project the compiled versions just need to be loaded from the dll if it's not already in memory (yes code can be garbage collected too, but less often). Loading that from the dll is 10 - 100 times faster (that's from the Razor Generator project's site - I didn't verify it myself, but it sounds reasonable).

Community
  • 1
  • 1
gangelo
  • 3,034
  • 4
  • 29
  • 43
  • 1
    All his points are technically true. Feel free to read my experiences and solution http://stackoverflow.com/questions/14866711/asp-net-mvc-mvcbuildviews-increasing-compile-time-drastically/14867003#14867003 – Dave Alperovich Apr 17 '13 at 20:34
  • why not add it as a response so I can mark it as the answer, if you throw in how pre-compiling stacks up to iis7 auto start? – gangelo Apr 19 '13 at 17:13
  • I hope this speaks to the question... – Dave Alperovich Apr 19 '13 at 17:38

1 Answers1

7

We struggled with the same problem. We began compiling Views in order to catch obvious issues that would creep up on us during Integration Tests and UX Tests. Even worse were the bugs that somehow crept into production.

But, our build times became intolerable. Our developers build countless times and that became a major part of our day. We had jokes about testing after lunch so the build could be done while we were out.

We eventually moved to building before UX-tests.

Now we are moving toward pre-compiling. Only one guy on our team has adopted it for now and apparently pre-compiles are noticably better than builds (incremental vs total). And setup is basically a nuget fetch.

These articles should be a good start

http://stacktoheap.com/blog/2013/01/19/precompiling-razor-views-in-asp-dot-net-mvc-3/

http://blog.davidebbo.com/2011/06/precompile-your-mvc-views-using.html

Pre-compiling gives us all the advantages of deploying ready built binaries. Our users don't experience the momentary lag the first time a View is hit.

As far as I know IIS autostart = true will start you Application Pool but will not force compile your Views. As a result, you're left with the initial start-up hit for the first user to use each View.

Dave Alperovich
  • 32,320
  • 8
  • 79
  • 101