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
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?
The text was updated successfully, but these errors were encountered:
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 forgetUnpackedByteLength()
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?The text was updated successfully, but these errors were encountered: