-
Notifications
You must be signed in to change notification settings - Fork 72
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
Consideration for a streaming Decoder
#27
Comments
Can only really use an encoder currently since there is no streaming api in `msgspec` as of currently. See jcrist/msgspec#27. Not sure if any encoding speedups are currently noticeable especially without any validation going on yet XD. First experiments toward #196
A streaming API for a deserializer is hard to support, since the internal state of the decoder needs to be kept throughout all operations so that it can be resumed later on. This comes with a performance hit for non-streaming decoding, and would complicate the codebase. Implementing it would require changes to the parser statemachine, which is all implemented at the C level (so no, Cython wouldn't work here). Rather, I recommend implementing message framing at a higher level. A simple protocol would be length prefix framing (see e.g. this blog post for reference). This has a few benefits besides simplifying our codebase:
|
@jcrist cool, this def makes sense to me. Are you suggesting that a framing protocol could be added to this project or you're suggesting client code should implement it in its own code base? Thanks again for the in depth answers btw. |
This would be something you'd handle in your own codebase. A naive asyncio implementation might be (untested, please note I don't have these apis memorized): async def write(stream, msg: bytes) -> None:
n = len(msg)
stream.write(n.to_bytes(4, "big"))
socket.write(msg)
await stream.drain()
async def read(stream) -> bytes:
prefix = await stream.readexactly(4)
n = int.from_bytes(prefix, "big")
return await stream.readexactly(n) |
Can only really use an encoder currently since there is no streaming api in `msgspec` as of currently. See jcrist/msgspec#27. Not sure if any encoding speedups are currently noticeable especially without any validation going on yet XD. First experiments toward #196
Can only really use an encoder currently since there is no streaming api in `msgspec` as of currently. See jcrist/msgspec#27. Not sure if any encoding speedups are currently noticeable especially without any validation going on yet XD. First experiments toward #196
Can only really use an encoder currently since there is no streaming api in `msgspec` as of currently. See jcrist/msgspec#27. Not sure if any encoding speedups are currently noticeable especially without any validation going on yet XD. First experiments toward #196
Can only really use an encoder currently since there is no streaming api in `msgspec` as of currently. See jcrist/msgspec#27. Not sure if any encoding speedups are currently noticeable especially without any validation going on yet XD. First experiments toward #196
Can only really use an encoder currently since there is no streaming api in `msgspec` as of currently. See jcrist/msgspec#27. Not sure if any encoding speedups are currently noticeable especially without any validation going on yet XD. First experiments toward #196
Can only really use an encoder currently since there is no streaming api in `msgspec` as of currently. See jcrist/msgspec#27. Not sure if any encoding speedups are currently noticeable especially without any validation going on yet XD. First experiments toward #196
Can only really use an encoder currently since there is no streaming api in `msgspec` as of currently. See jcrist/msgspec#27. Not sure if any encoding speedups are currently noticeable especially without any validation going on yet XD. First experiments toward #196
Can only really use an encoder currently since there is no streaming api in `msgspec` as of currently. See jcrist/msgspec#27. Not sure if any encoding speedups are currently noticeable especially without any validation going on yet XD. First experiments toward #196
Can only really use an encoder currently since there is no streaming api in `msgspec` as of currently. See jcrist/msgspec#27. Not sure if any encoding speedups are currently noticeable especially without any validation going on yet XD. First experiments toward #196
Can only really use an encoder currently since there is no streaming api in `msgspec` as of currently. See jcrist/msgspec#27. Not sure if any encoding speedups are currently noticeable especially without any validation going on yet XD. First experiments toward #196
Can only really use an encoder currently since there is no streaming api in `msgspec` as of currently. See jcrist/msgspec#27. Not sure if any encoding speedups are currently noticeable especially without any validation going on yet XD. First experiments toward #196
I was able to get basic funtionality integrated into a project but got hung up on not having an easy way to decode streamed
msgpack
data into objects incrementally.msgpack-python
offers the streamingUnpacker
api which is implemented in cython.I would be great to get something similar in this project for convenient stream processing without having to do manual parsing for object message delimiters.
I would be interested to provide a patch for this support.
Would you accept one as such in
cython
or would you insist on C?The text was updated successfully, but these errors were encountered: