The implementation of iter.Pull and iter.Pull2 functions is based on
closures and sharing local state, which results in one heap allocation
for each captured variable.
The number of heap allocations can be reduced by grouping the state
shared between closures in a struct, allowing the compiler to allocate
all local variables in a single heap region instead of creating
individual heap objects for each variable.
This approach can sometimes have downsides when it couples unrelated
objects in a single memory region, preventing the garbage collector from
reclaiming unused memory. While technically only a subset of the local
state is shared between the next and stop functions, it seems unlikely
that retaining the rest of the state until stop is reclaimed would be
problematic in practice, since the two closures would often have very
similar lifetimes.
The change also reduces the total memory footprint due to alignment
rules, the two booleans can be packed in memory and sometimes can even
exist within the padding space of the v value. There is also less
metadata needed for the garbage collector to track each individual heap
allocation.
goos: darwin
goarch: arm64
pkg: iter
cpu: Apple M2 Pro
│ /tmp/bench.old │ /tmp/bench.new │
│ sec/op │ sec/op vs base │
Pull-12 218.6n ± 7% 146.1n ± 0% -33.19% (p=0.000 n=10)
Pull2-12 239.8n ± 5% 155.0n ± 5% -35.36% (p=0.000 n=10)
geomean 229.0n 150.5n -34.28%
│ /tmp/bench.old │ /tmp/bench.new │
│ B/op │ B/op vs base │
Pull-12 288.0 ± 0% 176.0 ± 0% -38.89% (p=0.000 n=10)
Pull2-12 312.0 ± 0% 176.0 ± 0% -43.59% (p=0.000 n=10)
geomean 299.8 176.0 -41.29%
│ /tmp/bench.old │ /tmp/bench.new │
│ allocs/op │ allocs/op vs base │
Pull-12 11.000 ± 0% 5.000 ± 0% -54.55% (p=0.000 n=10)
Pull2-12 12.000 ± 0% 5.000 ± 0% -58.33% (p=0.000 n=10)
geomean 11.49 5.000 -56.48%
Change-Id: Iccbe233e8ae11066087ffa4781b66489d0d410a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/552375
Reviewed-by: Sean Liao <sean@liao.dev>
Auto-Submit: Sean Liao <sean@liao.dev>
Reviewed-by: qiu laidongfeng2 <2645477756@qq.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In introducing iterators, package iter gives an example of how to
use an iterator in a range-over-func loop, but currently does not
give an example of what an iterator implementation might look like.
This change adds the example of map.Keys() before the usage example.
Additionally, it references to the Go blog for further examples,
as well as the language spec about for-range loops.
Fixes#70986
Change-Id: I7108d341d314d7de146b4c221700736c943a9f5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/638895
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
The two tests confused a nil pointer panic with the panic from a double
call to yield.
Change-Id: I0040e60cf4b702a92825d308db1201a85f164009
Reviewed-on: https://go-review.googlesource.com/c/go/+/617917
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Remove old return value. Use single variable range for iter.Seq[V].
Rewrite Pairs implementation to not loop forever.
Fixes#68056Fixes#68073
Change-Id: I7ede0fe8ed058bbd57869d87e17b7f2c3641f7dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/593555
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Add the doc comment from the proposal, lightly edited.
The edits are to drop mention of value-error Seq2 usage
and to adjust for the bool result changes.
Fixes#61897.
Change-Id: Iaffbaa301064b2f8739956d602ca5fa23c89a269
Reviewed-on: https://go-review.googlesource.com/c/go/+/591096
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Consider the following code snippet:
next, stop := iter.Pull(seq)
stop()
Today, seq will iterate exactly once before it notices that its
iteration is invalid to begin with. This effect is observable in a
variety of ways. For example, if the iterator panics, since that panic
must propagate to the caller of stop. But if the iterator is stateful in
anyway, then it may update some state.
This is somewhat unexpected and because it's observable, can be depended
upon. This behavior does not align well with other possible
implementations of Pull, like CPS performed by the compiler. It's also
just odd to let even one iteration happen, precisely because of
unexpected state modification.
Fix this by not iterating at all of the done flag is set before entering
the iterator.
For #67712.
Change-Id: I18162e29df45a2e8968f68379450d92e1de47c4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/590075
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change propagates a runtime.Goexit initiated by the iterator into
the caller of next and/or stop.
Fixes#67712.
Change-Id: I5bb8d22f749fce39ce4f587148c5fc71aee2af65
Reviewed-on: https://go-review.googlesource.com/c/go/+/589137
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: David Chase <drchase@google.com>
This change propagates panics from the iterator passed to Pull through
next and stop. Once the panic occurs, next and stop become no-ops (the
iterator is invalidated).
For #67712.
Change-Id: I05e45601d4d10acdf51b53e3164bd891c1b324ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/589136
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently TestPull is flaky because goroutines spawned to run subtests
exit asynchronously when they finish and TestPull has explicit checks
for the number of existing goroutines.
This is pretty much only a problem between subtests executing, because
within each subtest the coroutine goroutine spawned for iter.Pull always
exits fully synchronously before the final `next` or `stop` returns.
So, we can resolve the problem by ensuring the first goroutine count the
test takes likely doesn't contain any exiting goroutines. The trick is
to set GOMAXPROCS=1 and spin in runtime.Gosched until the number of
goroutines stabilizes to some reasonable degree (we pick 100 consecutive
iterations; there are only a handful of possible goroutines that can
run, so this is giving that handful around 20 chances to actually run to
completion).
When running TestPull under stress2, this issue is easily reproducible
before this CL. After this CL, it no longer reproduces under these
conditions.
Fixes#66017.
Change-Id: I4bf0a9771f7364df7dd58f8aeb3ae26742d5746f
Reviewed-on: https://go-review.googlesource.com/c/go/+/587917
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently it's possible for next and yield to be called out of sequence,
which will result in surprising behavior due to the implementation.
Because we blindly coroswitch between goroutines, calling next from the
iterator, or yield from the calling goroutine, will actually switch back
to the other goroutine. In the case of next, we'll switch back with a
stale (or zero) value: the results are basically garbage. In the case of
yield, we're switching back to the *same* goroutine, which will crash in
the runtime.
This change adds a single bool to ensure that next and yield are always
called in sequence. That is, every next must always be paired with a
yield before continuing. This restricts what can be done with Pull, but
prevents observing some truly strange behaviors that the user of Pull
likely did not intend, or can't easily predict.
Change-Id: I6f72461f49c5635d6914bc5b968ad6970cd3c734
Reviewed-on: https://go-review.googlesource.com/c/go/+/583676
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
These were previously only available with GOEXPERIMENT=rangefunc.
For #61897.
Change-Id: I86aea5ae8be1f7a2975b623325811221ed40d384
Reviewed-on: https://go-review.googlesource.com/c/go/+/557836
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Pull2 tests are failing with -race, giving false-positive race conditions
due to bad race instrumentation.
No tests for this as it should be caught by the race builders. The only
reason it was not caught is because it is behind GOEXPERIMENT=rangefunc.
Fixes#64651
Change-Id: I20554da930b0e19594e0e267f01a1e7a9cbc577a
GitHub-Last-Rev: 7c1f19238d
GitHub-Pull-Request: golang/go#64653
Reviewed-on: https://go-review.googlesource.com/c/go/+/548895
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The exported API is only available with GOEXPERIMENT=rangefunc.
This will let Go 1.22 users who want to experiment with rangefuncs
access an efficient implementation of iter.Pull and iter.Pull2.
For #61897.
Change-Id: I6ef5fa8f117567efe4029b7b8b0f4d9b85697fb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/543319
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Achille Roussel
Harald Albrecht
Elias Naur
Ian Lance Taylor
Russ Cox
Michael Anthony Knyszek
Mauri de Souza Meneguzzo