-
Notifications
You must be signed in to change notification settings - Fork 0
Improve perf many state items #372
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
Conversation
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.
The change from SortedArray to Dictionary improves performance for direct key lookups and updates, but introduces a significant performance regression for prefix/range queries in readAll and createIterator. These functions now iterate and sort the entire dataset, which will be slow for large state sets.
| // Filter and sort entries | ||
| let filtered = store | ||
| .filter { $0.key.starts(with: prefix) } | ||
| .filter { $0.key.lexicographicallyPrecedes(startKey) == false } | ||
| .sorted { $0.key.lexicographicallyPrecedes($1.key) } | ||
|
|
||
| // Apply limit if specified | ||
| if let limit { | ||
| return Array(filtered.prefix(Int(limit))) | ||
| } | ||
| return resp | ||
|
|
||
| return filtered |
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.
The implementation of readAll has a performance regression. It filters and sorts the entire store dictionary, which is an O(N) operation to filter plus a sort on the filtered results. The previous SortedArray-based implementation was more efficient for this, as it could find the starting key in O(log N) and iterate from there. For a large store, this change will be very slow and may negate the performance gains in other functions. A similar issue exists for createIterator on lines 90-96.
If this trade-off is acceptable, the two separate .filter calls on lines 32 and 33 should be combined for slightly better performance.
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.
should be fine, readAll is not used anywhere, read is frequently used, and single read and write achieve O(1) is very meaningful for now
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #372 +/- ##
==========================================
- Coverage 81.68% 81.66% -0.03%
==========================================
Files 379 379
Lines 25919 25903 -16
==========================================
- Hits 21172 21153 -19
- Misses 4747 4750 +3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
some trace have lots of state items
improve in-mem backend a bit, state trie is more difficult to improve