-
-
Notifications
You must be signed in to change notification settings - Fork 138
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
Use a once-allocated buffer for reading native pixel values instead of using binary.Read (which allocates a slice under the hood) #163
Conversation
catching up with upstream
Benchmarks looking nice
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @kaxap for the contribution! The improvement looks great from avoiding binary.Read
which allocates a slice each time and instead manually unpacking the bytes into the right uint by reusing a once-allocated buffer.
Generally looks good, however I had some comments for you to consider before I merge.
Thanks again for the improvement :D
read.go
Outdated
} | ||
if n < bitsAllocated/8 { | ||
return nil, bytesRead, | ||
fmt.Errorf("not enough bytes in the input to read uint%d", bitsAllocated) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a thought: can we create a sentinel error for this (e.g ErrorIncompleteRead
or something) and wrap that error with the right bitsAllocated info?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, could we maybe add a test case here to trigger this and expect we get this type of error? we would have to update the test to use errors.Is
. Also, I can send a change for this later too if we prefer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
Co-authored-by: Suyash Kumar <suyashkumar2003@gmail.com>
Co-authored-by: Suyash Kumar <suyashkumar2003@gmail.com>
Co-authored-by: Suyash Kumar <suyashkumar2003@gmail.com>
Co-authored-by: Suyash Kumar <suyashkumar2003@gmail.com>
Add test for ErrorIncompleteRead minor refactoring
@suyashkumar appreciate your suggestions, implemented all of them I believe. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks so much for making those updates! I think it's looking pretty much good to go, I just had one final set of thoughts for you to consider and then let's get this merged. Thank you again for the contribution 😄
read.go
Outdated
val, err := d.ReadUInt8() | ||
if err != nil { | ||
return nil, bytesRead, err | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: no need for a new line here (but I can also just fix in a cleanup pr later, don't need to block this).
read.go
Outdated
if err != nil { | ||
return nil, bytesRead, err | ||
|
||
n, err := d.Read(pixelBuf) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thought about this a little more the second time around (sorry for not bringing this up earlier). Looking at the io.Reader
interface I think a single call to read may read "up to len(p)" bytes. Perhaps we should use io.ReadFull
to try to read at least the size of the buffer.
In reality for values like 16 or 32 bits, calls to Read
may still work no problem, but it may be more "correct" to use something like io.ReadFull
which won't be expensive in the case that Read
would've worked on the first try. This may also insulate us from the exact implementation of the reader under the hood we're reading from, since there is no garuntee that it must fill the buffer on the first call to Read
(but it's possible it may fill the buffer correctly on subsequent calls to Read
--see the implementation of ReadAtLeast).
It also looks like based on the implementation, it may return a nice ErrUnexpectedEOF if it reads less than n bytes, saving us an error, but we can leave it in there for not and not depend on that to make it easy and get this merged for now.
WDYT?
n, err := d.Read(pixelBuf) | |
n, err := io.ReadFull(d, pixelBuf) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. Read(buffer)
can in fact return less than n
bytes when reading from a network socket, which is expected behaviour.
Remove ErrorIncompleteRead as a consequence Update ReadNativeFrames test accordingly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks for making the suggested updates and thanks for the contribution!
🎉 merged! |
addressing #161