4 ms·

Do you have data for that? Whenever I tried to find actual data for this Linq seemed to be slightly slower, but not too much. Examples: https://codereview.sta

Do you have data for that? Whenever I tried to find actual data for this Linq seemed to be slightly slower, but not too much. Examples: https://codereview.stackexchange.com/questions/14197/is-the-linq-version-faster-than-the-foreach-one https://codereview.stackexchange.com/questions/14197/is-the-... https://wheresmykeyboard.com/2015/06/linq-lambda-loop-performance-test/ https://wheresmykeyboard.com/2015/06/linq-lambda-loop-perfor...

gameswithgo 7y ago
Yes. The total slowdown you get will depend on how much of the work being done is the actual iteration vs the work inside the loop. If you are doing a long running thing each time you go through the loop, then the overhead of the linq iteration is not so bad But something like: var sum = values.Sum(x => x * x); will take ~10x longer than an for or foreach loop equivalent. (260ms vs 36ms on 32 million float32s on my machine, measured by benchmarkdotnet) plus a small allocation
- smt88 7y ago
  You're right, but for most people writing C#, the developer time saved by Linq (being easier to read and understand quickly) is much more valuable than the tiny amount of CPU time that's lost.
- roetlich 7y ago
  Thanks for your reply. I'm fairly new to C#, and was hoping that linq would make my life easier. Oh well. I made some benchmarks myself: https://pastebin.com/5vQNpbPC https://pastebin.com/5vQNpbPC And esp. the Sum is a lot slower in linq. Not quite an order of magnitude, but pretty bad. Even worse: float sum = 0; arr.Select(x => (sum += x * x)).ToList(); return sum; This is somehow still a lot faster than the normal linq Sum. What does .Sum() do to be this slow? Edit: I just noticed you also wrote this blog post on the topic: https://jackmott.github.io/programming/2016/07/22/making-obvious-fast.html https://jackmott.github.io/programming/2016/07/22/making-obv... I should have read that earlier!
  - louthy 7y ago
    You're doing more work though. You're converting to a List<T> (in order to caox the lazy enumerable to enumerate). You should use Aggregate for a more (generalised) way to reduce/fold collections into a value: var sum = arr.Aggregate(0, (t, x) => t + (x * x)); On the whole though it's better to use Linq until it's not. It's more declarative which will lead to more reliable code. Optimise when you find performance issues, don't write bad code just because you may gain a few nanoseconds here and there.
- patsplat 7y ago
  If your workload is summing 32 million float32s use foreach. Otherwise pay for readability with CPU.
- louthy 7y ago
  Bear in mind that the operation is trivial and so the overhead cost of invoking the lambda per iteration becomes more significant. I'm not trying to dismiss the performance differences, but summing 32 million floats is not a common use-case and I think the performance differences are mostly irrelevant for those using it to (for example) sum a list of line-items for an invoice or whatever. For anyone that needs maximum performance then they should clearly be wary of anything that requires invocation of lambdas, but the usefulness of Linq shouldn't be written off because of that - the declarative style leads to fewer bugs, more stable, maintainable and easier to read code - that in itself is a performance boost.

gameswithgo 7y ago

Yes. The total slowdown you get will depend on how much of the work being done is the actual iteration vs the work inside the loop. If you are doing a long running thing each time you go through the loop, then the overhead of the linq iteration is not so bad But something like: var sum = values.Sum(x => x * x); will take ~10x longer than an for or foreach loop equivalent. (260ms vs 36ms on 32 million float32s on my machine, measured by benchmarkdotnet) plus a small allocation

smt88 7y ago
You're right, but for most people writing C#, the developer time saved by Linq (being easier to read and understand quickly) is much more valuable than the tiny amount of CPU time that's lost.
roetlich 7y ago
Thanks for your reply. I'm fairly new to C#, and was hoping that linq would make my life easier. Oh well. I made some benchmarks myself: https://pastebin.com/5vQNpbPC https://pastebin.com/5vQNpbPC And esp. the Sum is a lot slower in linq. Not quite an order of magnitude, but pretty bad. Even worse: float sum = 0; arr.Select(x => (sum += x * x)).ToList(); return sum; This is somehow still a lot faster than the normal linq Sum. What does .Sum() do to be this slow? Edit: I just noticed you also wrote this blog post on the topic: https://jackmott.github.io/programming/2016/07/22/making-obvious-fast.html https://jackmott.github.io/programming/2016/07/22/making-obv... I should have read that earlier!
- louthy 7y ago
  You're doing more work though. You're converting to a List<T> (in order to caox the lazy enumerable to enumerate). You should use Aggregate for a more (generalised) way to reduce/fold collections into a value: var sum = arr.Aggregate(0, (t, x) => t + (x * x)); On the whole though it's better to use Linq until it's not. It's more declarative which will lead to more reliable code. Optimise when you find performance issues, don't write bad code just because you may gain a few nanoseconds here and there.
patsplat 7y ago
If your workload is summing 32 million float32s use foreach. Otherwise pay for readability with CPU.
louthy 7y ago
Bear in mind that the operation is trivial and so the overhead cost of invoking the lambda per iteration becomes more significant. I'm not trying to dismiss the performance differences, but summing 32 million floats is not a common use-case and I think the performance differences are mostly irrelevant for those using it to (for example) sum a list of line-items for an invoice or whatever. For anyone that needs maximum performance then they should clearly be wary of anything that requires invocation of lambdas, but the usefulness of Linq shouldn't be written off because of that - the declarative style leads to fewer bugs, more stable, maintainable and easier to read code - that in itself is a performance boost.