On the performance of “Opinionated Builders”

I was reading Eric Hexter’s post titled “Opinionated Input Builders Part 6: Performance of the Builders” and I was going to leave a lengthy comment, but decided it would be better as its own blog post:

I’m going to assume that the data is all correct (or representative of reality). As another reader pointed out, this [poor performance] could simply be because debug=true is set in the web.config or some other non-obvious, but simple explanation. For this exercise, let’s assume that this performance is the correct reality.

Since [Eric’s] approach is very opinionated and conventional, I would expect it to result in very consistent and expected results (code written in the same way, files in the same place, etc).

This consistency is key because you could write some sort of pre-compiler that could inline the partials or something before pushing to production.If there isn’t already a tool to do this, I would imagine it wouldn’t be that hard to write.

"But now I have to write a tool to do what ASP.NET could do for me already!  This input builder stuff just ain’t worth it!" a skeptic might say.

But consider this:  Doing it WITHOUT input builders may slow you down 20% vs. doing it WITH them (I’m just making numbers up here, but you get the point).  Over an 8 week project with 4 people (1280 man-hours), that’s a savings of 256 man-hours.  I’m pretty sure that you could easily write some sort of in-liner or pre-compiler in 256 man-hours (6.4 man-weeks) and you’d end up with either a net-zero or a net-gain on the project.

I’m of the firm belief that you do what’s expedient for the project (YAGNI unless you’re absolutely certain you WILL NEED it), and deal with performance issues later in a systematic way.  Performance problems are always easier to deal with later and with more data from which to make a better decision and especially so if you’re consistent and conventional in your development (which Opinionated Input Builders certainly are).

So for those who might immediately turn their noses up at Eric’s posts due to suspected performance issues, I suggest you at least give it a second look or give it a little time as an optimizer might show up later, negating most if not all performance issues.

Related Articles:

    Post Footer automatically generated by Add Post Footer Plugin for wordpress.

    About Chad Myers

    Chad Myers is the Director of Development for Dovetail Software, in Austin, TX, where he leads a premiere software team building complex enterprise software products. Chad is a .NET software developer specializing in enterprise software designs and architectures. He has over 12 years of software development experience and a proven track record of Agile, test-driven project leadership using both Microsoft and open source tools. He is a community leader who speaks at the Austin .NET User's Group, the ADNUG Code Camp, and participates in various development communities and open source projects.
    This entry was posted in Premature optimization. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
    • benhyrman

      The problem with getting hung up on the performance of those input builders is that one would have to written an app:

      – that is data-entry intensive
      – where the biggest performance issue is partial views
      – and is only using partial views in relation to the input builders