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

unpacking should work segment-by-segment #69

Open
jdiaz5513 opened this issue Sep 19, 2017 · 0 comments
Open

unpacking should work segment-by-segment #69

jdiaz5513 opened this issue Sep 19, 2017 · 0 comments

Comments

@jdiaz5513
Copy link
Owner

jdiaz5513 commented Sep 19, 2017

Right now, unpack runs on the entire packed ArrayBuffer and combines all the message's segments into a single ArrayBuffer, including the stream frame header.

This is silly, given that it's going to need to be split up again into separate buffers soon afterward in Message.getFramedSegments(). A (huge?) number of CPU cycles can be saved by enabling the unpack algorithm to receive byte offset and expected length arguments. Once the expected number of words have been unpacked the unpack function should return what it got up to that point, including an offset to where it stopped unpacking. That'll also eliminate the need for getUnpackedByteLength() while unpacking since the stream frame header will dictate the length of each segment.

To avoid multiple return values in unpack() (ick!) it's probably sane to pass a destination ArrayBuffer that's already allocated to the right size, and use that for the expected length. It makes it harder to just unpack an arbitrary buffer of bytes with unknown final size, but will that ever be needed?

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

No branches or pull requests

1 participant