On Tue, Dec 31, 2024 at 1:40 PM Axel Wagner <axel.wagner...@googlemail.com> wrote:
> > Please note that "maps.Collect" is slow. > https://github.com/golang/go/issues/68261 > > Please note that I did address that in my message. > CollectN matters most for non-trivial iterators, e.g. where you first > transform an iterator using `xiter.Map` or the like. > Something like slices.Collect(maps.Keys(m)) - which this discussion is > about - can be relatively easily optimized by the compiler, if we want. > I doubt it is easily. > > > This is typical micro benchmark. There are too such "allocating and then > throwing away small slices" cases in Go programming. The iterator cases are > just a tiny portion of them. > > I was talking about end-to-end execution time of the program. In a > CPU-bound program, it is not uncommon for allocations in the inner loop to > have significant effects. > Let's focus the specific topic. Do you ranging over map.Keys and map.Values is faster than directly range over maps? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAHbs%3DNZXx1ejkYQMvUc9dLpVmG6yLCkao7qUGEGexhUOnjoiDQ%40mail.gmail.com.
