3 ms·
About step 2: You still need to drop items, that's required for Vec<T> to be sound. By not calling `Vec::clear` and instead using pub struct RepeatedField<
by K0nserv 3y ago
About step 2: You still need to drop items, that's required for Vec<T> to be sound. By not calling `Vec::clear` and instead using
pub struct RepeatedField<T> {
vec: Vec<T>,
len: usize,
}
with indexing patterns like `self.vec[..self.len]` and setting `self.len = 0` to clear you avoid the cost of dropping all items at once(like Vec::clear does). However you still have to drop items, so with this solution the cost is amortised in `RepeatedField::push` and other methods that do `self.vec[i] = new_item`.
> It's designed to avoid the drop overhead
Isn't true. You don't avoid the the overhead, at most you delay/amortise it.
- v0y4g3r 3y agoWriteRequest::timeseries is a vector (https://github.com/prometheus/prometheus/blob/main/prompb/remote.proto#L23 https://github.com/prometheus/prometheus/blob/main/prompb/re...) and the repeated file `Timeseries::labels` and `Timeseries::samples` are reused across different timeseries. You don't have to alloc a new vector for the lables and samples for each new timeseries instance.
- K0nserv 3y agoThat would be true if you used `Vec::clear` too, it doesn't allocate a new vector. My point was that you still end up running Drop implementations with RepeatedField<T>, just not all at once. See https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=75621151b0a3e81da16741a24f8f9e96 https://play.rust-lang.org/?version=stable&mode=debug&editio...