After doing what all good developers should do on the weekend… which is enjoy life and spend some time with my family, I thought I would take another stab at the Input Builder performance and see what else I could learn about the implementation. That being said this is what I came up with.
Want to get a 2X increase in 5 seconds of development time?
One of the features of the Builders that I like is the ability to deliver all of the partial views from a separate assembly that would make this library and approach feel more like a component with a single package for all of its files than a Hodge-podge of files you need to copy into your project. That approach came at a cost. My own implementation of the VirtualPathProvider proved to be disastrous on performance. Below is the same performance test running against my sample page with the partial views and master pages copied into the local project and removing my implementation of the VirtualPathProvider.
With this small 5 second change the Maximum Requests/Second went from 442 to 1,027 . The Average Requests/Second went from 351 to 908. Not bad huh? So after a single change to the code base and removing my custom code for pulling partial views from the embedded resources, I was able to get a huge performance increase.
What are the next steps?
Since I still like the approach of having the virtual path provider I will spend a little time looking into how I can change the implementation so that it renders better performance. Now that I have better performance out of the builders it will be good for me to take a 2nd pass with the profiler and see where the hot spots are. My hunch is the bottle neck in this code is something that I wrote versus something that comes out of the box with the framework. So there will be more work to do on this front but at this point I am positive that I can overcome the performance aspects of this approach and I will concentrate on a few more posts which discuss more of the opinions as well as more of the implementation.