Skip to content

Conversation

@martinsumner
Copy link
Contributor

Marginal gains for frequently called functions - see eprof profile #25

Always keep vclocks sorted - and use the sorting to speed-up comparison.

Also try to optimise the naming functions when we're naming riak_kv_vnode.

Still the outstanding issue of the long IndexName - commonly with about 150 0s - making the integer_to_list/list_to_binary conversion unnecessarily hard.
As going to do two descends - so don't do two sorts
We're going to look this up over and over - so don't recalculate
Keep test to use for future potential refactoring
Speed up for options fetching, but just on metadata get.

The vclock will now support a future when the bucket properties is a map - i.e because a map is passed around in riak_kv instead of a list.
@martinsumner martinsumner merged commit 2669f0f into openriak-3.4 Nov 5, 2025
2 checks passed
@github-project-automation github-project-automation bot moved this from In review to Done in OpenRiak 3.4 Nov 5, 2025
@martinsumner martinsumner deleted the nhse-o34-orc.i25-efficiency branch November 5, 2025 10:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants