You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would the team take any exception to a proposal to add a method to AsyncBufferedByteIterator that could copy more than one byte at a time to an UnsafeMutableRawBufferPointer or similar? It seems that if you were, say, chewing through 1 GB of data, copying chunks at a time using copyBytes(from:), copyMemory(from:), or one of the other fancy versions of memcpy in the standard library could have the potential to be a lot more efficient than calling next() literally one billion times...
Yes, I know the compiler can do a lot of inlining and other optimizations here, but c'mon, you can't beat memcpy in a speed contest.
The text was updated successfully, but these errors were encountered:
Chunked nexts is something that is high on our list but we don't have the language features just yet to express it the way we want. Passing a raw pointer from the next method isn't great because that pointer would need to point into the contents of the internal buffer. Furthermore, the ownership of that pointer is undefined as in the can the consumer just escape that wherever he wants? What is the lifetime of that pointer?
There is a lot of work in the language happening right now to give us the tools to express this properly. The currently worked on Span type is ~Escapable and would solve the ownership questions. We could then use that to pass an opaque but performant chunk from the next method.
Would the team take any exception to a proposal to add a method to
AsyncBufferedByteIterator
that could copy more than one byte at a time to anUnsafeMutableRawBufferPointer
or similar? It seems that if you were, say, chewing through 1 GB of data, copying chunks at a time usingcopyBytes(from:)
,copyMemory(from:)
, or one of the other fancy versions ofmemcpy
in the standard library could have the potential to be a lot more efficient than callingnext()
literally one billion times...Yes, I know the compiler can do a lot of inlining and other optimizations here, but c'mon, you can't beat
memcpy
in a speed contest.The text was updated successfully, but these errors were encountered: