-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Remove unused memorystore.Size() #9680
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
base: main
Are you sure you want to change the base?
Remove unused memorystore.Size() #9680
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: ankit98040 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @ankit98040. Thanks for your PR. I'm waiting for a github.com member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
WalkthroughRemoved the Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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.
Actionable comments posted: 0
🧹 Nitpick comments (2)
internal/memorystore/memory_store.go (2)
46-48: Optional: Consider explicit counter initialization for clarity.The
countfield relies on Go's zero-value initialization (0 for atomic.Int64), which is correct for an empty store. While this works perfectly, you could make the intent more explicit:func New[T AnyCreated[T]]() Storer[T] { - return &memoryStore[T]{s: sync.Map{}} + return &memoryStore[T]{ + s: sync.Map{}, + count: atomic.Int64{}, + } }This has no functional benefit but may improve readability.
40-43: Add a comment explaining the counter's purpose.As per coding guidelines, add comments explaining 'why' not 'what'. The
countfield should be documented to explain its purpose as a performance optimization.📝 Suggested documentation
type memoryStore[T AnyCreated[T]] struct { s sync.Map + // count maintains the number of elements in the store for O(1) Size() queries. + // It's updated atomically during Add() and Delete() operations. count atomic.Int64 }Based on coding guidelines: "Add comments explaining 'why' not 'what' in Go code".
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
internal/memorystore/memory_store.go
🧰 Additional context used
📓 Path-based instructions (1)
**/*.go
📄 CodeRabbit inference engine (AGENTS.md)
**/*.go: Use interface-based design and dependency injection patterns in Go code
Propagate context.Context through function calls in Go code
Usefmt.Errorfwith%wfor error wrapping in Go code
Use logrus with structured fields for logging in Go code
Add comments explaining 'why' not 'what' in Go code
Use platform-specific file naming:*_{linux,freebsd}.gofor platform-dependent code
Files:
internal/memorystore/memory_store.go
🧠 Learnings (2)
📚 Learning: 2025-12-17T13:38:34.646Z
Learnt from: bitoku
Repo: cri-o/cri-o PR: 9667
File: server/container_create.go:1233-1236
Timestamp: 2025-12-17T13:38:34.646Z
Learning: In the cri-o/cri-o repository, protobuf-generated Get* methods for k8s.io/cri-api types are nil-safe: if the receiver is nil, GetX() returns the zero value instead of panicking. Do not add explicit nil checks before chaining calls on such getters. Apply this guidance to all Go code that uses these generated getters across the codebase.
Applied to files:
internal/memorystore/memory_store.go
📚 Learning: 2025-12-18T13:28:24.244Z
Learnt from: bitoku
Repo: cri-o/cri-o PR: 9676
File: internal/lib/stats/cgroup_stats_unsupported.go:1-7
Timestamp: 2025-12-18T13:28:24.244Z
Learning: In the cri-o/cri-o repository, for platform-specific types guarded by Go build tags (for example //go:build !linux), implement empty structs for unsupported platforms to permit compilation and clearly indicate the feature is not available rather than mirroring the Linux struct with unpopulated fields. Apply this pattern to all relevant platform-specific files across the codebase (i.e., any file under build-taged sections that should compile on all targets but lacks full implementation for some platforms).
Applied to files:
internal/memorystore/memory_store.go
🔇 Additional comments (5)
internal/memorystore/memory_store.go (5)
5-5: LGTM: Import addition is appropriate.The
sync/atomicimport is required for the atomic.Int64 counter operations.
53-55: LGTM: Add() logic correctly handles inserts vs. updates.Using
Swap()with theloadedreturn value ensures the counter is incremented only when a new key is inserted, not when updating an existing key. This maintains an accurate count.
72-74: LGTM: Delete() logic correctly handles actual removals.Using
LoadAndDelete()with theloadedreturn value ensures the counter is decremented only when a key is actually removed, not when attempting to delete a non-existent key. This maintains an accurate count.
87-88: LGTM: Size() now runs in O(1) time.The atomic counter approach successfully eliminates the need to iterate over the map, achieving the performance goal stated in the PR objectives.
41-42: Eventual consistency between map and counter is a real concern; verify if acceptable for use case.The code has a consistency window:
c.s.Swap()/c.s.LoadAndDelete()andc.count.Add()are separate operations on different objects. A concurrentSize()call can observe a count that lags behind the actual map state. Assess whether callers tolerate this eventual consistency or if operations must be coordinated under a shared lock.
|
Thank you for the PR @ankit98040 ! In fact, Size() is only used in this test here. (correct me if I'm wrong) cri-o/internal/memorystore/memory_store_test.go Lines 51 to 66 in fbbc7bf
So this optimization should degrade the performance unfortunately because of unnecessary size management though It should be negligible. |
The Size() method was only used in one test and added unnecessary overhead. This commit removes it entirely: - Removed Size() from Storer interface - Removed Size() implementation from memoryStore - Updated test to remove redundant Size() assertion This eliminates the O(N) iteration cost and prevents future misuse of this inefficient method. Signed-off-by: Ankit Pramanik <[email protected]>
8c4aed8 to
fa5afc5
Compare
|
/ok-to-test |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
This PR optimizes the
Size()method ininternal/memorystorefrom O(N) to O(1) complexity by maintaining an atomic counter instead of iterating over the entiresync.Mapon every call.Problem: The previous implementation iterated over all entries in the map to count them, which becomes inefficient as the number of containers/sandboxes grows.
Solution:
atomic.Int64counter to track the number of elements in the storeAdd()to useSwap()and increment the counter only for new keysDelete()to useLoadAndDelete()and decrement the counter only when a key is actually removedSize()to simply return the atomic counter valueThis improves performance for operations that frequently check the store size, especially in environments with many containers.
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
The changes are thread-safe as they use atomic operations and the existing
sync.Mapguarantees. The logic ensures:Add) does not increment the counterI verified the correctness with a standalone test that validates Add, Update, and Delete operations maintain accurate counts.
Does this PR introduce a user-facing change?
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.