Added a benchmark:

Sorry, that benchmark was compiled in Debug mode. Here's the Release variant:

I just noticed that this is essentially reverting 439d6dc#diff-945d1a38da3eef0446f42a82a64b7ead, however all tests still pass. This PR should not be affected by the issue described in #184 because we are ensuring that each element is acted upon on the same event loop.

In addition, the 3x performance gain from this PR is too important to pass up, given that flatten is actually becoming a bottle neck in several almost-synchronous parts (i.e. we use futures, but almost all of them are fulfilled right away) of Vapor (e.g. vapor/template-kit#50). (We still need to maintain correctness, of course.)

@adtrevor, would you mind taking a look at this PR?

The .flatten method was recently changed in this PR because it was found that it had some threading issue. You might want to make sure this PR doesn't re-introduce them.

@MrMage Everything looks correct to me! :)

The .flatten method was recently changed in this PR because it was found that it had some threading issue. You might want to make sure this PR doesn't re-introduce them.

See #199 (comment) :-)

@MrMage I guess we posted at about the same time 😄. Sounds good!

Just to double check, would it be possible for us to use whenAllSucceeded like we are doing for Vapor 4 in NIOKit?

No idea about the performance of whenAllSucceed. I think we should merge this PR now, and when upgrading Core to NIO2, benchmark the performance of whenAllSucceed vs. this implementation before using whenAllSucceed.

Or will this Core.flatten method simply be removed with Vapor 4 in favor of NIOKit.flatten? If so, we should still benchmark the performance of NIOKit.flatten vs. Core.flatten.

@MrMage Core is being remove from Vapor 4, so you would go with the second option. But in reality, we won't be updating Core to NIO 2 because Vapor 3 uses NIO 1.

@MrMage Core is being remove from Vapor 4, so you would go with the second option. But in reality, we won't be updating Core to NIO 2 because Vapor 3 uses NIO 1.

Thanks for the info! That makes sense. I think we should benchmark NIOKit's flatten implementation then.

Update: no need for changes in NIOKit; I hope to upstream these into NIO with apple/swift-nio#943.

Hey @MrMage, you just merged a pull request, have a coin!

You now have 19 coins.