Sharpy performance testing
I recently introduced Sharpy – a view engine designed to allow developers and designers to work together. Today I’m going to take a look at the performance of the view engine when compared to the default view engine.
Compiled vs. Interpreted
The default ASP.NET view engine uses compiled views – the entire view gets transformed into a piece of code which in turn gets compiled and invoked at run time. This was advertised as one of the major benefits of ASP.NET when compared to regular ASP – since regular ASP consisted mainly of scripts written in either JScript or VBScript there were numerous performance issues. Keep in mind that the regular view engine still needs to parse the files – it needs to look for the ASP tags (<% and %>) and figure out what is code and what is HTML.
Sharpy works a little differently – firstly, the views are interpreted, not compiled. While this would indicate that we’re back to the old days of ASP, we’re not. Keep in mind that every Sharpy function and modifier is already a piece of compiled code. For example, if you use the foreach function you are simply invoking a piece of compiled code – only expressions are evaluated at runtime.
Having said that – I wanted to do some actual performance testing to see the difference between the 2 view engines. I knew that Sharpy would be slower, but I wanted to check that’s it’s not by a significant amount.
Performance testing
To do the performance testing I extended both the default MVC view engine and Sharpy view engine and simply wrapped the CreateView method in a timer. I then wrote a fairly complex view and duplicated the functionality in Sharpy syntax. I was trying to figure out the worst-case scenario – this would be a view with loads of expressions which needed to be evaluated.
The immediate results were quite interesting – both view engines can create a view in far less than a millisecond. I then changed the scenario to force each view engine to render the view a million times. This gave me a much better view – Sharpy is about 10 times worse than the default view engine in the worst-case scenario. In my tests, run on a 64-bit 2.2 GHz Intel Core 2 Duo with 4 GB of ram Sharpy took about 400 milliseconds versus 40 for the default view engine. This means if your website gets a million hits at once both view engines can render all the content in less than half a second.
Conclusions
The performance testing confirmed what I was expecting – Sharpy is slower than the default view engine, but not by a significant amount. If you can render a million views in 400 milliseconds your bottleneck will still be the database, not the view engine (which is the way it should be).
Having said that, I think there are some improvements that can be made here. I did play around with caching – this would simply cache the parsed data for each view which you can enable in the configuration. I would also like to explore the possibility of moving to a more compiled approach to have a look at the performance benefits.
I would like to hear some feedback on this – I can’t really decide if it would be worth moving to this model. If you have any thoughts on this please leave a comment below.
Happy coding.