Opinionated Input Builders Part 6 – Performance of the builders

• Part 1 – Overview
• Part 2 – the Label
• Part 3 – the Source Code
• Part 4 – the Partial View
• Part 5 – the Required Field Indicator 
• Part 6 – the Performance

Update – 6/14/2009 Chad Myers blogged about the trade offs and the importance of productivity over premature optimizations.

– Please see the second set of tests I ran for a large performance increase.

Multiple people asked about the performance implications of using this style of input builders.  First let me say that as far as performance, using the partial views is probably the least efficient way to render html.  But with every approach there are tradeoffs. In this case we are trading run time performance for developer productivity and codebase and user interface consistency. That being said I cannot answer what the best approach is for you. That depends on the size of your team , the size of your project, the skill set of your team and a number of other aspects which determine what the best approach is.  For instance I would not use input builders or a MVC view if I was building a form to collect votes for American Idol.  I would actually create the forms in static html pages.  The scalability would require the best performing solution.

The Control Test

With any good test you have to have a control case. In this case I ran a load test against an empty MVC view that was using the same Master Page as my form page.  I ran a constant load against that page in IIS 7, on a x64 Vista OS for 10 minutes.  The results is that I have a maximum Request / Second of 1,622 and an Average Requests / Second of 1,275. You can see the chart below of the Requests/Second.

The Load Test

Next I ran the same test against the page I have used for all of the samples in this series.  With the same load , machine configuration, and duration as the control test.  In this case my Maximum Requests/Second was 442 and the Average Requests/Second were 351.  What does that mean?  I lost 75% of my page request through put by using the Input Builders. Does this mean we should not use the input builders?  The answer is … it depends.  What through put do you need? From my experience I have found that most forms backed by a data store cannot scale to 400 Requets / Sec without some significant architectural principles in play.  Such as asynchronous messaging and other methods to scale. 

What are the next steps for performance?

The next step for me is running the load test with a Profiler attached to the process.  I used the JetBrains Dot Trace application.  It is nice because after I run the profile session and analyze the data it has a quick and dirty Hot Spot report.  This show the single biggest offender of my codebase.  This means that if I optimize the code below that will have the biggest improvement for performance.  It is a combination of the time it takes to execute this code combined with the number of times this code path is executed.  That being said, lets dig into it. 

The 3rd call in this stack is part of the RenderPartial call I do not totally understand the internals of the MVC view engine and I will not pretend to. If I really wanted to see more it would make sense to pull down the MVC source code and build it with is symbol files, than the profiler could give me more information.  So what I am surprised by is that my hunch when first thinking about performance would have taken me to the reflection and Lamda Expression code, but this test shows that the biggest bottle neck is in the control / partial rendering.  So by using this tool I have saved myself a huge headache by preventing myself from optimizing the wrong code.  At this point I am going to put this information together and get it in front of those in the .Net Community who are way smarter than I am and of course, get it to the brainiacs at Microsoft who wrote this stuff to suggest some approaches for better performance . They know their internal benchmarks as well as what they are planning for the future. 

The biggest lesson I can demonstrate here is do not pre optimize.  I already wasted 20 minutes of my time and Jimmy Bogard’s time talking about different ways to optimize Lambda Expressions.  It is clear that implementing those optimizations would not make a single difference in effecting the output of this performance test.

###

Should you use the builders?

Well that decision is really up to you, but I hoped that I demonstrated a scientific approach to answering that question. For me the componentization of the HTML and the productivity increases of using the builders far outweigh the runtime performance issues.  Again, I would take this on a case by case basis and when I need more throughput than what I can provide with this approach I would consider a different method of mark up generation.