Avoid creating a yield ID counter per async writer #2768
Conversation
glbrntt
added
the
patch-version-bump-only
Motivation: The NIOAsyncWriter uses an atomic to generate yield IDs. Each writer has its own atomic. We can save an allocatiuon per writer but using a shared atomic. Each load then wrapping increment operation with relaxed ordering takes approx 3ns on my machine. For a UInt64 this would take approx 188 years to wrap around if run in a tight loop. Modification: - Share a single yield ID counter for NIOAsyncWriter Result: Fewer allocations
glbrntt
force-pushed
the
shared-yield-id-generator
branch
from
46ed6c1
to
921a1ad
Compare
| @@ -17,6 +17,9 @@ import DequeModule | |||
| import NIOConcurrencyHelpers | |||
| import _NIODataStructures | |||
|
|
|||
| @usableFromInline | |||
| let yieldIDCounter = ManagedAtomic<UInt64>(0) | |||
There was a problem hiding this comment.
This would probably be nicer as a static, but this is otherwise reasonable.
There was a problem hiding this comment.
Agreed but wasn't sure where to put it. The obvious place is NIOAsyncWriter but that's generic so can't have a static let.
There was a problem hiding this comment.
I am not sure if I agree with this move. I understand that we want to reduce allocations but IMO the correct move forward is to replace SwiftAtomics.ManagedAtomic with Synchronisation.Atomic which should avoid the allocation as well since it is ~Copyable. We ought to be able to do this conditionally when the compiler is Swift 6. Though availability might be tricky. If availability blocks us we can move this into a global. I would suggest renaming though to scope it better e.g. let _asyncWriterYieldIDCounter or something like that
There was a problem hiding this comment.
I agree re: using Synchronization.Atomic but as noted, the availability makes this difficult. I've renamed the global though.
Motivation:
The NIOAsyncWriter uses an atomic to generate yield IDs. Each writer has its own atomic. We can save an allocatiuon per writer but using a shared atomic.
Each load then wrapping increment operation with relaxed ordering takes approx 3ns on my machine. For a UInt64 this would take approx 188 years to wrap around if run in a tight loop.
Modification:
Result:
Fewer allocations