5 ms·

Optimization tips

messel 17y ago
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 17y ago
  Find? Look at his other submissions--I think he's the author. A lot of the other articles are excellent too.
solutionyogi 17y ago
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-considered-somewhat-harmful.aspx 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.
- camccann 17y ago
  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 17y ago
    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-tree-basics.aspx http://blogs.msdn.com/charlie/archive/2008/01/31/expression-... 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 17y ago
This is why I keep reading Hacker News. Excellent practical advice!

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 17y ago
Find? Look at his other submissions--I think he's the author. A lot of the other articles are excellent too.

solutionyogi 17y ago

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-considered-somewhat-harmful.aspx 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.

camccann 17y ago
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 17y ago
  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-tree-basics.aspx http://blogs.msdn.com/charlie/archive/2008/01/31/expression-... 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 17y ago

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