Can one of the admins verify this patch?

That is simply not correct!

You have changed lazy in two places. Lets first talk about about theDictionary.init(_:uniquingKeysWith:) at line 607:

I have slightly modified the test as I wasn't sure how you have createdallobjects but I can't reproduce your test results. Here is my modified version:

@inline(never)func blackHole(_ value:someAny){}func lazy(){letallobjects=Array(repeating:1, count:100)varcounter=0letduration=ContinuousClock().measure{for_in0..<1_000_000{            counter+=Dictionary(allobjects[0..<40].lazy.map({($0,1)}), uniquingKeysWith:+).values.first!}}blackHole(counter)print("lazy", duration)}func eager(){letallobjects=Array(repeating:1, count:100)varcounter=0letduration=ContinuousClock().measure{for_in0..<1_000_000{            counter+=Dictionary(allobjects[0..<40].map({($0,1)}), uniquingKeysWith:+).values.first!}}blackHole(counter)print("eager", duration)}lazy()eager()

which prints in release mode with swift-5.7-DEVELOPMENT-SNAPSHOT-2022-07-17-a:

lazy 5.722392167000001 secondseager 6.738160625 seconds

This makes perfect sense as no intermediate array is allocated becauseDictionary.init(_:uniquingKeysWith:) takessome Sequence as it's input.

However, I think you are right about the second place where you have changed lazy:

The solution to this is a bit ugly as we need to usewithoutActuallyEscaping and would look something like this:

varconnectionToCreate=withoutActuallyEscaping({(eventLoop:EventLoop)->HTTPConnectionPool.Connection.IDinself.createNewOverflowConnection(on: eventLoop)}){ createNewOverflowConnectionOnEventLoopin    requiredEventLoopOfPendingRequests.flatMap{ eventLoop, requestCount->LazyMapSequence<LazySequence<StrideTo<Int>>.Elements,(HTTPConnectionPool.Connection.ID,EventLoop)>in           // We need a connection for each queued request with a required event loop.           // Therefore, we look how many request we have queued for a given `eventLoop` and           // how many connections we are already starting on the given `eventLoop`.           // If we have not enough, we will create additional connections to have at least           // on connection per request.letconnectionsToStart= requestCount- startingRequiredEventLoopConnectionCount[eventLoop.id, default:0]returnstride(from:0, to: connectionsToStart, by:1).lazy.map{ _in(createNewOverflowConnectionOnEventLoop(eventLoop), eventLoop)}}}

I haven't tested the performance but I'm quite confident that this will improve performance too as we do not allocate an intermediate array.

As this makes the code a bit harder to follow I ended up not using thewithoutActuallyEscaping trick. Thelazy is just an artifact I forgot while reverting the change. Aslazy has no effect here, we could just remove it.@Lukasa what do you think? Is it worth the complexity to use the non-allocatingwithoutActuallyEscaping trick or should we just removelazy?

In the second case you're right that.lazy is entirely unnecessary. Sorry about the confusion there, that's my fault. As constructed, the.lazy achieves nothing, because we're specifying that we're returning anArray. I definitely don't think we gain enough to justify usingwithoutActuallyEscaping, which is a pattern I generally dislike.

However, in the case of Dictionary construction there remains insufficient evidence to make the case that this flow optimises the intermediate Array away. That allocation is extraordinarily painful, and it's worth removingeven though.lazy is a substantially slower way to iterate.

As a sidebar, if we really wanted to make this faster the way to do it is to replace this functional code that feels like it wants to use.lazy with imperative iteration. Swift is substantially better at optimising the latter (due to the absence of escaping closures).