Avoid useless memory copies in IPC reader.#2510
Conversation
Signed-off-by: remzi <[email protected]>
| let start_offset = buf.offset() as usize; | ||
| let end_offset = start_offset + buf.length() as usize; | ||
| let buf_data = &a_data[start_offset..end_offset]; | ||
| let buf_data = Buffer::from(&a_data[start_offset..end_offset]); |
There was a problem hiding this comment.
As we cannot slice on Buffer with length, we cannot implement a_data as a Buffer
There was a problem hiding this comment.
Looking at the calculation above, I think we don't need to truncate the length, as end_offset is the end of the buffer?
There was a problem hiding this comment.
The end_offset is the end of buf, but not sure whether it is the end of a_data
There was a problem hiding this comment.
Aah yes, brain fart on my part. R.e. making a_data a Buffer, we could always pass the length separately...
tustvold
left a comment
There was a problem hiding this comment.
There is definitely more that could be done here, but this is a solid start 👍
|
Benchmark runs are scheduled for baseline = 601968b and contender = ebe3d43. ebe3d43 is a master commit associated with this PR. Results will be available as each benchmark for each run completes. |
|
Thank you, @tustvold |
|
I don't believe there is a particular reason, I think lifting length out of |
|
Wow that was fast 🚀 |
| // no compression | ||
| let data = &input[(LENGTH_OF_PREFIX_DATA as usize)..]; | ||
| Buffer::from(data) | ||
| input.slice(LENGTH_OF_PREFIX_DATA as usize) |
Signed-off-by: remzi [email protected]
Which issue does this PR close?
Closes #2437.
Rationale for this change
What changes are included in this PR?
Are there any user-facing changes?
Yes.