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.
