Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consumption of multiple bytes at once from AsyncBufferedByteIterator? #315

Open
CharlesJS opened this issue Jun 6, 2024 · 1 comment
Open

Comments

@CharlesJS
Copy link

CharlesJS commented Jun 6, 2024

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.

@FranzBusch
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants