Simple apply/filter/reduce package in Go

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

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).

[ Parent | on HN ]

Re:Simple apply/filter/reduce package in Go by inglor on Friday April 03, 2015 @11:56AM (#9316561)

In particular - the Microsoft .NET JIT will gladly make them as fast as loops in most cases - there might be overhead involving closures but that's mostly taken care of.

[ Parent | on HN ]