Re:Simple apply/filter/reduce package in Go
by pcwalton on Friday April 03, 2015 @11:43AM
(#9316464)
> .NET iterators are objects that implement a specific interface, and iterating over them involves two function calls per element - one to move to the next item, and one to retrieve the current item.
Any optimizing compiler will inline those functions. "Avoid function calls for performance" hasn't been relevant optimization advice for at least a decade.
Re:Simple apply/filter/reduce package in Go
by bunderbunder on Friday April 03, 2015 @01:58PM
(#9317338)
A good optimizer can inline those functions, but that doesn't necessarily mean it will. .NET JIT is conservative in what it decides to inline. There's even a special hint you can use to ask it to be more aggressive about inlining a method. You can't necessarily apply that hint to every function, though. Anonymous ones, for example.
Re:Simple apply/filter/reduce package in Go
by pcwalton on Friday April 03, 2015 @02:34PM
(#9317550)
> A good optimizer can inline those functions, but that doesn't necessarily mean it will.
If the optimizer isn't choosing to inline where it is a performance win, it's not a good optimizer.
Especially for trivial functions like Current() and MoveNext(), which are pretty much the textbook example of functions where inlining really helps (not so much because of the function call overhead, but because it enables so many intraprocedural loop optimizations).
Those two function calls introduce an overhead that may be significant in a "tight loop", and that may not exist in a hand-coded for loop.
Perhaps .NET's optimizer is smart enough to get things down to a for loop equivalent in some cases, but in general I haven't seen much evidence of that happening.