Wow, that’s really useful! Which would be your preference @twittemb ?
Hard to say, depending in the flexibility we want. I like the existential version since it offers flexibility (keeping the protocol) while hiding implementation details to the developers.
I've done some more measurements (always using an .unbounded policy) that seem to confirm that the 4 variations have the same throughput (running 10 times the throughput and making an average).
They seem to have a 6% increased perf compared to the actor version.
Can you think of a better measurement protocol that could put forward one choice over the other?
TBH I was wondering that myself. I was looking at how long the tests took to execute in Xcode when ‘run repeatedly’ for 100 iterations, but I think that’s a poor test as it won’t include compiler optimisations as you’d get in a release build.
I think we may need something along these lines.
I’ll do a small plug here:
Might be interesting to see context switches and Mallocs too depending on what’s tested.
Need to install jemalloc though (brew)
2 Likes
Hi,
For the record, here is the PR that implements a buffer operator with customisable storage with generics (not using actors) -> [Buffer] implement with customizable storages by twittemb · Pull Request #239 · apple/swift-async-algorithms · GitHub
That implementation seems considerably more robust. It looses a touch of potential ease for developers to implement their own custom buffer, but that is probably an ok sacrifice for correctness.
2 Likes