

Optimization tips - clawrencewenham
http://sites.google.com/site/yacoset/Home/optimization-tips

======
messel
Excellent find and share Clawrence.

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.

~~~
camccann
Find? Look at his other submissions--I think he's the author. A lot of the
other articles are excellent too.

------
solutionyogi
For the section titled "LINQ? Return expressions, not results", the query
returns an 'Iterator'/'Query' and not an 'Expression Tree'. They are
completely different things. The underlying point is valid that it makes sense
to return the query so that the caller can do perform additional
filtering/grouping, if needed.

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-...](http://blogs.msdn.com/ericlippert/archive/2008/09/22/arrays-
considered-somewhat-harmful.aspx)

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.

~~~
camccann
_For the section titled "LINQ? Return expressions, not results", the query
returns an 'Iterator'/'Query' and not an 'Expression Tree'. They are
completely different things. The underlying point is valid that it makes sense
to return the query so that the caller can do perform additional
filtering/grouping, if needed._

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.

~~~
solutionyogi
LINQ is made possible using Expression Trees but the query itself is not
expression tree. Read this article, it will give you a good head start.
[http://blogs.msdn.com/charlie/archive/2008/01/31/expression-...](http://blogs.msdn.com/charlie/archive/2008/01/31/expression-
tree-basics.aspx)

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.

------
tyrmored
This is why I keep reading Hacker News. Excellent practical advice!

