Optimize buffering in log_to_sinks #330
Conversation
| @@ -32,6 +32,7 @@ serde_repr = "0.1.19" | |||
| serde_with = { version = "3.12.0", features = ["macros", "base64"] } | |||
| serde.workspace = true | |||
| smallvec = "1.14.0" | |||
| smallbytes = "0.1.0" | |||
There was a problem hiding this comment.
Hm, this crate appears to be fresh abandonware...
... but it looks like the stars have aligned, and impl BufMut for SmallVec was recently added to smallvec, to be released with v2.0.0!
There was a problem hiding this comment.
Nice. I think let's start with this and then we can remove the smallbytes dependency later.
There was a problem hiding this comment.
Sure. Let's file a linear ticket so we don't forget.
| } | ||
| Err(_) => { | ||
| // Likely the stack buffer was too small, so fall back to a heap buffer. | ||
| let mut size = msg.encoded_len().unwrap_or(STACK_BUFFER_SIZE * 2); |
There was a problem hiding this comment.
I'm a little surprised we don't benefit more from the encoded_len() hint. Which message sizes did you benchmark against?
There was a problem hiding this comment.
I was testing with 440 kg message sizes.
In practice what happens is everything goes into the stack buffer, then the data field is serialized, it either fits or it's too big and it grows the buffer to fit. Remaining fields won't be enough to cause it to grow again.
I think we could still use encoded_len with reserve or similar, but it doesn't make a difference.
There was a problem hiding this comment.
Well, what if you had several big fields? Couldn't each one theoretically trigger a new allocation as the serializer attempts to write them, one after another?
There was a problem hiding this comment.
I added a call to reserve(). It might be a little slower in some cases as encoded_len() is recursive and not that cheap for prost. Should be minor compared to the memory copy cost.
Changelog
Improve logging performance by ~20%
Description
This actually simplifies the code. I had to bring in the SmallBytes crate for a BufMut wrapper around SmallVec.