3 ms·
You'll notice the functional iterators under iter/ don't include benchmarks. Go will not inline a function that exceeds complexity metrics, and one of those me
by mappu 5y ago
You'll notice the functional iterators under iter/ don't include benchmarks.
Go will not inline a function that exceeds complexity metrics, and one of those metrics is whether the function contains a range statement. You will get a real heap-allocated closure invocation on each loop.
Go's function calls are not that cheap, and these will be measurably slower than the for-loop equivalent. I see functional idioms as being a huge risk factor for Go.
- felixge 5y ago> Go will not inline a function that exceeds complexity metrics True, but: > and one of those metrics is whether the function contains a range statement. You will get a real heap-allocated closure invocation on each loop. I think this is no longer true in Go 1.18, see https://github.com/golang/go/issues/14768#issuecomment-981759381 https://github.com/golang/go/issues/14768#issuecomment-98175... .
- zyedidia 5y agoAuthor here. I think there is definitely room for improvement in the iterator API. I intend to experiment with more implementations in the coming weeks with the goal of settling on something better by the time Go 1.18 is released. The main alternative I have in mind is a cursor-style iterator (for example, with `Next`, `Done`, and `Value` methods). If you have something else in mind too, let me know and I might be able to try it out.
- lucian1900 5y agoI think the cursor alternative works best with Go's syntax. it := GetAnIterator() for it.Next() { it.Value() } This still allows composition of different iterators, for building up lazy/incremental processing.
- lazyjones 5y agoIt should not be hard to automatically convert code using such generics libraries to use specialized type-specific code instead for better performance.
- deleted 5y ago[deleted]