Optimization tips
sites.google.com
sites.google.com
Worrying too much on the front end about optimization not only inhibits productivity, but results in wasteful optimizing since the majority of our bottlenecks reside in a few key areas. And we may not know or have coded those areas until the project is well under way.
Also, it's great idea to convert query results to List instead of an array. See Eric Lippert's blog on 'Arrays Considered Harmful.' http://blogs.msdn.com/ericlippert/archive/2008/09/22/arrays-...
Section: Immutable strings? Use String.Format() and StringBuilder
For the given example, practically, there is no difference in performance for two code samples. I hate micro optimizations. Use the version which makes the code easier to read.
I take serious objection to the tip - 'Minimize the number of variables'. Code readability/maintainability is much more important so use as many variables as you need. Only after you have profiled the code and found that using 3 variables instead of 5 variables gives you performance boost (which I doubt will ever happen), remove those extra variables.
It reads to me as if he's saying that query comprehensions like that essentially parse the code and store the structure of the query in a completely unevaluated manner, like the expression trees that a compiler operates on, including things like decomposing more complicated expressions into simpler lambdas, and that the whole thing is lazy-evaluated and hidden behind the enumerator interface.
So, if the queries are optimized before running, tacking additional clauses onto an unevaluated query would allow it to rearrange the execution plan in arbitrary ways, including moving clauses into different parts of what would (I assume) be some sort of a tree-structured representation of the query.
But I'm not an expert on LINQ, so maybe it is a misuse of terminology. I know I've heard expression trees mentioned in a LINQ-related context, but I don't recall the details.
For the given example, practically, there is no difference in performance for two code samples. I hate micro optimizations. Use the version which makes the code easier to read.
If you're doing string concatenation in a loop, this isn't really a micro optimization, it's a serious change in the algorithmic time complexity of the loop. His example was a trivial illustration, but the point is valid.
Also, your understanding of his point is valid and I agree with it, I did mention that in my original comment. I was acting pedantic about terminology.
And I did not question the advice of using StringBuilder when concatenating strings in a loop, I questioned the advice to use string.Format instead of using '+' operator.