Permanently Compiling views in RazorMachine

[ltoshev]

Hi

I have a need to warm up all my views i.e. compile them before I start using them. The idea is to lower the times of the first user that hits the site. I added code that compiles all my views and it is triggered by the load balancer. The problem is that it takes ages to warm up all views and I cannot get the server out of warm up mode. The same warm up is needed after recycling and this is a big problem for our production environment.

I've looked through the code in RazorMachine and I have the following idea: to compile all views to actual files(dlls) and deploy them as well.

In order to achieve this I need to modify the library in the following way:

In TemplateFactory.cs there is a method: CreateAssembly()

I can change the compilation to be GenerateInMemory = false, and to set OutputAssembly = "to a path" that comes from RazorConfig. (i.e. my bin folder)

i.e. I need to modify the current code which looks like this:

new CompilerParameters(_razorContext.Config.References.ToArray()) { GenerateInMemory = true, CompilerOptions = "/optimize" };

Then I can make a console application in my project that invokes RazorMachine with settings to generate assemblies(RazorConfig will needs some settings about this to work) and the console app will precompile all my views to disk. This console app will be triggered as part of the deployment procedure.

After that I just need to initialize RazorMachine to load the right assemblies in TemplateFactory.cs in CreateBucket() method instead of going in and trying to compile them on runtime.

What do you think about this approach? Is it doable, do you see any gotchas? Will you accept a merge request to put this change into the library if I implement it?

Regards,
L. Toshev

[jlamfers]

Razor Machine is a JIT compiler based template compiler. The whole approach is based on that.
One thing to reckon with is that Razor Machine monitors template changes and recompiles on the next request after any source change. I think my approach would be to implement a persistent cache for the compiled assemblies using the server's file sytem in some temp folder (in stead of in memory which is the current approach), and name these assemblies using a hash code based on the template source. Then after a restart your application must reuse these compiled assemblies (for those without source changes) in stead of recompile the templates. For that approach the type caching needs to be refactored, it should be implemented behind an interface. Then depending on your needs you could configure the file based persistent type cache, or the in memory type cache, or any whatever cache. With this approach you would not need a helper console application for precompiling and you would not have to manually deploy your assemblies.

Still a fresh install would require a JIT compilation of all assemblies. Maybe you could put that work inside a low priority background process (controlled by the application itself) that starts to precompile all the template assemblies as soon as the application starts for the first time, while it is serving requests as well.

Its up to you how you build it. If you implement a manner that does not require manual compilation and still feels like a "jitter" than I am very open for adding that to razor machine.

[jrnail23]

I was wondering a bit about this issue myself -- basically, if RazorGenerator could be used in conjunction with RazorMachine. The primary benefit for me being compile-time checking. That, along with a view locator that uses the compiled view type (unless a physical file exists at the deploy path -- a-la RazorGenerator's MVC view engine) seems like it could do the trick.

Any thoughts?