Marking synchronous implementation of AsyncIteratorProtocol with "await" makes it much slower

[saagarjha]

Description

I have an AsyncSequence that is actually fully synchronous (shown below). If I implement next() without async and compile with optimizations then iterating over it easily hits a billion or more iterations per second. However, if I mark next() as async (and make no other changes) then it runs 3-4 orders of magnitude slower.

Reproduction

struct TestSequence: AsyncSequence {
	struct AsyncIterator: AsyncIteratorProtocol {
		var iterator = (1...(.max)).makeIterator()

		mutating func next() -> Element? {
			iterator.next()
		}
	}

	func makeAsyncIterator() -> AsyncIterator {
		AsyncIterator()
	}

	typealias Element = Int
}

let sequence = TestSequence()

var last = 0
var lastTime = ContinuousClock.Instant.now

for await n in sequence where n % 1_000 == 0 {
	if ContinuousClock.Instant.now - lastTime > .seconds(1) {
		print(n - last, "iterations per second")
		last = n
		lastTime = ContinuousClock.Instant.now
	}
}

Expected behavior

If I add async to next() and compile with optimizations then I expect the same performance as the code above.

Environment

$ swiftc -version
swift-driver version: 1.87.3 Apple Swift version 5.9.2 (swiftlang-5.9.2.2.56 clang-1500.1.0.2.5)
Target: arm64-apple-macosx14.0

Additional information

No response

[weissi]

@saagarjha top-level Swift code is weird. You can get the expected performance if you do this

func GO() async {
    let sequence = TestSequence()

    var last = 0
    var lastTime = ContinuousClock.Instant.now

    for await n in sequence where n % 1_000 == 0 {
        if ContinuousClock.Instant.now - lastTime > .seconds(1) {
            print(n - last, "iterations per second")
            last = n
            lastTime = ContinuousClock.Instant.now
        }
    }
}

await GO()

so just stick your top-level code into a function and call the function.

[saagarjha]

Hmm, interesting. I pulled this out of another project that didn’t have top-level code, so let me investigate some more.

[weissi]

Hmm, interesting. I pulled this out of another project that didn’t have top-level code, so let me investigate some more.

You'll need these two ingredients for async code to go fast:

• Caller and callee(s) are in the same module (always allows inlining) or callee(s) is sufficiently @inlinable
• not top-level code it seems

Honestly, I didn't know about the top-level code pitfall so I thought your reproducer would fall into the 'pit of success' because it's all one module. But then I tried your code and discovered the top-level woes.

In your real project I wouldn't assume you have any real top-level code so I'd imagine it's a not-inlinable enough kinda problem