Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
perf: add cache to address codec #20122
base: main
Are you sure you want to change the base?
perf: add cache to address codec #20122
Changes from 6 commits
36ed3fe
23356b3
ac248de
274650b
45a6e11
7ffa4a7
de976c7
37bf7f5
469ac79
a608650
63e2eff
f5ccb72
726d5fc
8ca5ad1
9868c7f
9db0b77
5d5ab90
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
nit: this is always true
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.
Yeah, followed the same style as in address.go, although I think it doesn't make much sense.
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.
personal preference: it would be great to have this configurable so people can trade CPU for memory or not.
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.
Agreed. I'm not sure what the best approach is to solve this, as LRUs are currently shared between codecs and defined as globals.
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.
🤔 do we need 3 different cache types? I was wondering if this is for sharding or pinning maybe? The LRU should keep the frequently used ones in cache anyway? WDYT?
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 bytes of the addresses are the same, but there are three possible outputs (AccAddress, ValAddress, ConsAddress). I see three options here:
map["cosmos"] = "cosmos1dr3..."
)I've chosen the first option to maintain consistency with how things were done before.
cosmos-sdk/types/address.go
Lines 100 to 111 in 8e60f3b
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.
Not sure if this is possible but in case the bytes match an existing bech32 address, it can create some trouble. Adding key prefixes may solve this or not sharing the same cache.
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.
See first comment. Currently, there are three different caches, but adding key prefixes may be a solution if we prefer just one.
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.
Can there be more than 1 bech32 prefix per type? The cache is global and may return wrong strings for the byte representation.
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.
Most of the time its gonna be just one bech32 prefix. But there may be uses cases with more than one. For example someone who wants to develop a multi chain client. In those cases this cache may be a problem.
I'm more inclined to add the prefix to the key now. Or not share LRUs between codecs at all.
🤔🤔🤔
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 problem is BytesToString for an address as this path may not point to an unique address. A unique cache key prefix for each
cachedBech32Codec
instance to the byte key would prevent this. You can keep the global cache but would require a global index for the bech32 prefix to cache prefix as well so thatNewBech32Codec(prefix string)
resolve to the same cache key prefix.The alternative is a cache per
cachedBech32Codec
as you pointed out. This gives a better isolation but it comes with the cost of extra memory which can be a lot. You would still need a global index but for the bech32 prefix to cache now.A third alternative is caching for the default bech32 prefixes defined in Config only. With this approach you won't need indexes or cache key prefixes. I would assume it would cover the majority of use cases on a chain.
Nevertheless, there is complexity to pass these defaults to the cache on initialization.
I have some preference on option 3 but option 1 can also work well
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.
I think caches defined prefix should be sufficient, we can concatenate the prefix to the bytes as a key.
cosmos-sdk/codec/address/bech32_codec.go
Lines 15 to 17 in 5a5c638
E.g. if two address codecs are defined with prefixes
cosmos
andosmo
the LRU table'll look like this: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.
This would work as well. 👍 Keys get bigger but they are unique
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.
🤔 it can be worth to cache failures, too. Some benchmarks would be interesting.
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.
Optimize locking strategy in
cachedBech32Codec
methods.The current implementation locks the entire method, which could lead to performance bottlenecks. Consider using a more granular locking strategy or other synchronization techniques like
sync.Map
which is optimized for the use case where the entry for a given key is only written once but read many times.