Wouldn’t you normally pass a consumer or collector function into the interator
code? Then you only write the iterator once, and it is hidden.
Similar to how the sync.Map.Range() works.
Barring that, I don’t see how
for(i:=c.Iterator();i.HasNext();) {
v := i.Next()
}
is that much more difficult to use - especially since you state it is a custom
iteration anyway?
> On Oct 25, 2018, at 1:51 PM, Eric S. Raymond <e...@thyrsus.com> wrote:
>
> Jan Mercl <0xj...@gmail.com>:
>> The 'obvious' way is not something I'd consider. The 'concise' way works
>> today, provided iterator function returns a slice or a map.
>
> Yes, but returning a slice (eager evaluation) is exactly what I want to avoid.
>
> The context: the repository where my Python version hit a performance wall
> has 259K events in it. It's the history of the GNU Compiler Collection.
>
> A very common thing for my code to need to do is to iterate over all events
> of a
> certain type - most often Commits, representing changes to filesets - so that
> it can select a subset to be passed to mutator code.
>
> I want to be able to say "for i, c := range repo.commits() {do_something(c)}",
> but without iterators this requires constructing an intermediate slice of
> commits only inside the commits() fuction, then passing that back to the
> range loop.
>
> That's annoying. Often I'm only going to use a small handful of those
> pointers.
> With eager list evaluation, Go's memory manager gets hammered as though I were
> going to use the entire list every time.
>
> Remember that I'm doing this translation to improve performance. I'm
> unavoidably
> going to do a lot of allocations when deserializing the repisitory into its
> in-memory attributed-graph form, but after that I really want to keep heap
> churn to the bare mimimum required by the surgical operations.
> --
> <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
>
> My work is funded by the Internet Civil Engineering Institute:
> https://icei.org
> Please visit their site and donate: the civilization you save might be your
> own.
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
--
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.
For more options, visit https://groups.google.com/d/optout.
