-
-
Notifications
You must be signed in to change notification settings - Fork 286
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
Reduce buffering between watcher
and Store
#1487
Comments
It's also been pointed out that this peak allocation might not deallocate at all for the default allocator. Important bits from a discord thread:
|
What problem are you trying to solve?
As a follow-up to watcher paging/streaming in an effort to reduce allocations and move the complexity to where it needs to be. The main problem here is allocation for initial lists (or initial streaming lists). These are essentially allocated twice internally:
watcher
'sstep_trampolined
Store
'sapply_watcher_event
If we can move the allocation into store and bubble up the event earlier, then we avoid double/triple allocating this, and users who write custom stores can avoid waiting or double allocating.
Note this buffering happens for both listwatch and for streaming lists.
Describe the solution you'd like
We can lift this caching with a
Page<Vec<K>>
orPartial<Vec<K>>
newwatcher::Event
that can be bubbled up to be inserted into the store. Because we now have a ready guard in the store it should be safe to start inserting into the store immediately (though it would have to be altered slightly to fire after a complete initial list/stream has happened).This is a small breaking change to the enum, but it is contained to very internal interfaces and can be documented.
Describe alternatives you've considered
watcher::Config
to decide whether to bubble up early, but it doesn't avoid the breaking change of introducing a new watcher event for partial data (even if we don't act on it) because it's not#[non_exhaustive]
watcher::Event
has extra features. this feels pretty hairy for an already complex watcher trampoline, and we eventually want the best performance to be the default, rather than hidden behind an opt-inDocumentation, Adoption, Migration Strategy
watcher::Event
will get a new variant to match onTarget crate for feature
kube-runtime
The text was updated successfully, but these errors were encountered: