2 ms·

Have they improved the implementation recently? I have not benchmarked myself, but according to [1], they are slower than the equivalent loop-based code. [

by azth 12y ago

Have they improved the implementation recently? I have not benchmarked myself, but according to [1], they are slower than the equivalent loop-based code. [1] http://arxiv.org/pdf/1406.6631v2.pdf

kasey_junk 12y ago
This paper rightly points out that there will be overhead of object creation and potentially virtual calls (though that will be very JIT dependent). That said, my cursory examination (and it was very cursory) of their benchmark for C# is that they are really benchmarking the time difference between the iterator of an IEnumerable (or maybe IList, don't have an ability to decompile it right now) and the highly optimized case of looping through an array (which is literally one of the most highly optimized tasks on modern commodity hardware). On one hand, it does prove their point that in certain very specialized cases (looping through an array with no abstraction atop it), you will have significant performance penalties in the generic iterator case. On the other, I'm not sure I would attribute this to LINQ. I'm reasonably certain (and in these cases the space "reasonably" represents could have a truck driven through it) if you were to write the same code as a foreach loop using the same iterator and generic collections you wouldn't see significant performance differences. I'm definitely confident in most "real world" uses, where you are already using generic collections and iterators, you should bias towards using the LINQ implementation (assuming you believe it is better code) until definitive performance testing proves otherwise. For instance, in the case of the sum of squares, that looks like classic loop unrolling optimizations not being applied which any indirection in the looping code can prevent. Further, they show that there already exist optimization libraries that can eliminate much of the overhead. I will say, I'm quite impressed by the java results on this benchmark. Also, I didn't write any tests to prove any of this, so could be wildly off the mark. Further, I've spent more time than i ever wanted either hand translating or writing macros to, translate high level collections code into while loops. But that was in an extremely performance sensitive environment.

by azth 12y ago

Have they improved the implementation recently? I have not benchmarked myself, but according to [1], they are slower than the equivalent loop-based code. [1] http://arxiv.org/pdf/1406.6631v2.pdf

kasey_junk 12y ago

This paper rightly points out that there will be overhead of object creation and potentially virtual calls (though that will be very JIT dependent). That said, my cursory examination (and it was very cursory) of their benchmark for C# is that they are really benchmarking the time difference between the iterator of an IEnumerable (or maybe IList, don't have an ability to decompile it right now) and the highly optimized case of looping through an array (which is literally one of the most highly optimized tasks on modern commodity hardware). On one hand, it does prove their point that in certain very specialized cases (looping through an array with no abstraction atop it), you will have significant performance penalties in the generic iterator case. On the other, I'm not sure I would attribute this to LINQ. I'm reasonably certain (and in these cases the space "reasonably" represents could have a truck driven through it) if you were to write the same code as a foreach loop using the same iterator and generic collections you wouldn't see significant performance differences. I'm definitely confident in most "real world" uses, where you are already using generic collections and iterators, you should bias towards using the LINQ implementation (assuming you believe it is better code) until definitive performance testing proves otherwise. For instance, in the case of the sum of squares, that looks like classic loop unrolling optimizations not being applied which any indirection in the looping code can prevent. Further, they show that there already exist optimization libraries that can eliminate much of the overhead. I will say, I'm quite impressed by the java results on this benchmark. Also, I didn't write any tests to prove any of this, so could be wildly off the mark. Further, I've spent more time than i ever wanted either hand translating or writing macros to, translate high level collections code into while loops. But that was in an extremely performance sensitive environment.