I think I'm an XMLReader poo pooer…

  <p>
    //Foo[1]/Bar[@val = &#8216;gerrard&#8217;]
  </p>
  
  <p>
    rather than ten or 15 lines of procedural code.
  </p>
  
  <p>
    Perf is great, but in most of my apps simple maintanability and easy ramp up are way more important that getting every single drop of speed&#8230;
  </p></blockquote> 
  
  <p>
    Today <a href="http://www.hanselman.com/blog/XmlAndTheNametable.aspx">Scott posted a follow-up</a>, including the following:
  </p>
  
  <blockquote>
    <p>
      I also received a number of poo-poo emails that said &#8220;use XPath&#8221; or &#8220;don&#8217;t bother&#8221; and &#8220;the performance is good enough.&#8221; 
      
      <p>
        Sure, if that works for you, that&#8217;s great. Of course, always measure before you make broad statements. That said, here&#8217;s a broad statement. Using an XmlReader will always be faster than the DOM and/or XmlSerializer. Always.
      </p></blockquote> 
      
      <p>
        Can I nominate myself for spokesman of the poo pooers? Call me the Mort Spokesman if you like ;).
      </p>
      
      <p>
        <a name="a000501more"></a><br /> <a id="more"></a>
      </p>
      
      <p>
        I don&#8217;t think anyone is suggesting that there isn&#8217;t a speed difference, only that the perf improvement may not be worth the decrease in readability and maintainability of the code. Again, I agree 100% that there is some perf difference, I just don&#8217;t believe it&#8217;s enough of a difference to make it worth the cost in terms of complexity.
      </p>
      
      <p>
        Beyond that, I can&#8217;t imagine many real world applications where that speed difference (even if it is orders of magnitude) isn&#8217;t going to be dwarfed by the time it takes to travel across a network and to run db transactions.
      </p>
      
      <p>
        I tend to design applications with the following questions in mind, in order of priority:
      </p>
      
      <p>
        <ol>
          </p> 
          
          <li>
            How easy is it to train a new developer to replace me?
          </li>
          <p>
          </p>
          
          <li>
            How easy will it be to fix a problem when one arises late on a Friday?
          </li>
          <p>
          </p>
          
          <li>
            How easy is it to change the application?
          </li>
          <p>
          </p>
          
          <li>
            How easy is it to expand the application?
          </li>
          <p>
          </p>
          
          <li>
            How will the application perform?
          </li>
          <p>
            </ol>
          </p>
          
          <p>
            Notice where perf is in that list. Most of the developers I have worked with are really challenged by the breadth of technologies and techniques available to them. Having the applications they maintain and support easy to understand, easy to troubleshoot and easy to modify is more important to me than optimizing for every single drop of perf possible. If it wasn&#8217;t, I&#8217;d probably be writing in Assembly. Or I&#8217;d try to get my job at the t-shirt factory back.
          </p>
          
          <p>
            Of course, it&#8217;s not a black and white issue. There are trade-offs and balances depending on who the user community is, and the business processes that you are supporting. Further, the old chestnut applies&#8230;test early and often. If it turns out that connecting to the db and running a sproc is less of a bottleneck for your app than your choice to use XPath instead of XMLReader, go for it! Optimize away.
          </p>
          
          <p>
            That said, I think the Alpha Geeks tend to focus on perf, and premature perf optimizations, to the exclusion of maintanability more often than is healthy. Especially if, like me, you don&#8217;t like working late ;). Remember, writing test programs with tight loops, and comparing coding patterns in terms of number of operations is fun for devs. Whether or not it adds business value to solutions is another question entirely.
          </p></p></div>