This benchmark examines how ValidateGenesis behaves.
In a follow-up issue, I'll show how it reveals an inefficiency
that'll affect trying to load repeatedly retrieve Validators'
ConsAddress values.
Updates #8744
* add zeroed custom fields check to tm client
* remove custom fields function from x/upgrade and fix tests
* use []byte in x/upgrade, move abci to 02-client
* remove x/ibc from types
* whoops, delete testing files
* fix upgrade tests
* fix tm tests
* fix tests
* update CHANGELOG
* revert proto breakage, use reserved field cc @amaurym
* add IBC Upgrade Proposal type
* remove IBC from upgrade types
* add IBC upgrade logic to 02-client
* fix all tests for x/upgrade
* Add CLI for IBC Upgrade Proposal
* Update x/ibc/core/02-client/types/proposal_test.go
Co-authored-by: Federico Kunze <31522760+fedekunze@users.noreply.github.com>
* add gRPC for upgraded client state
* test fixes
* add HandleUpgradeProposal tests
* update docs and remove unnecessary code
* self review bug and test fixes
* neatness
* construct empty rest handler
* fix tests
* fix stringer tests
* Update docs/core/proto-docs.md
Co-authored-by: Christopher Goes <cwgoes@pluranimity.org>
* add key in ibc store tracking ibc upgrade heights
Add a new Key to the IBC client store to track the IBC Upgrade Height. This allows IBC upgrades to correctly remove old IBC upgrade states
* update abci and tests
* revert key storage after discussion with @AdityaSripal
Revert using a key to track IBC upgrades. By clearing any IBC state using an old plan in ScheduleUpgrade, IBC upgrades do not need to be tracked by IBC. This reduces code complexity and reduces potential for bugs.
* clear IBC states on cancelled upgrades
Co-authored-by: Federico Kunze <31522760+fedekunze@users.noreply.github.com>
Co-authored-by: Christopher Goes <cwgoes@pluranimity.org>
* Use x/auth/client for querying Txs
* Fix lint
* Fix small test
* Update todos
* Move QueryTx functions to x/auth/tx
Co-authored-by: Alessio Treglia <alessio@tendermint.com>
* Consolidating codec.go registrations. Moving Acknowledgement result/error to its own file
* Updating CHANGELOG.md with #7949 improvement as requested
* revert removing acknowledgement proto to its own file
* update changelog
* remove unnecessary pb.go file
Co-authored-by: colin axnér <25233464+colin-axner@users.noreply.github.com>
Fix `keys migrate` command (#8703)
crypto/keyring: reinstate the InfoImporter interface
InfoImporter is implemented by those Keyring implementations
that support import of Info objects.
Co-authored-by: Alessio Treglia <alessio@tendermint.com>
Co-authored-by: Jonathan Gimeno <jgimeno@gmail.com>
Co-authored-by: Amaury <1293565+amaurym@users.noreply.github.com>
Previously, we set build_tags before updating the options for DB backend.
This does't work with BadgerDB - it BUILD_TAGS which must be included in build_tags.
Co-authored-by: Federico Kunze <31522760+fedekunze@users.noreply.github.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
After continuously profiling InitGensis with 100K accounts, it showed
pathologically slow code, that was the result of a couple of patterns:
* Unconditional and not always necessary map lookups
* O(n^2) sdk.AccAddressFromBech32 retrievals when the code is expensive,
during a quicksort
The remedy involved 4 parts:
* O(n) sdk.AccAddressFromBech32 invocations, down from O(n^2) in the quicksort
* Only doing map lookups when the domain key check has passed
* Using a black magic compiler technique of the map clearing idiom
* Zero allocation []byte<->string conversion
With 100K accounts, this brings InitGenesis down to ~6min, instead of
20+min, it reduces the sort code from ~7sec down to 50ms.
Also some simple benchmark reflect the change:
```shell
name old time/op new time/op delta
SanitizeBalances500-8 19.3ms ±10% 1.5ms ± 5% -92.46% (p=0.000 n=20+20)
SanitizeBalances1000-8 41.9ms ± 8% 3.0ms ±12% -92.92% (p=0.000 n=20+20)
name old alloc/op new alloc/op delta
SanitizeBalances500-8 9.05MB ± 6% 0.56MB ± 0% -93.76% (p=0.000 n=20+18)
SanitizeBalances1000-8 20.2MB ± 3% 1.1MB ± 0% -94.37% (p=0.000 n=20+19)
name old allocs/op new allocs/op delta
SanitizeBalances500-8 72.4k ± 6% 4.5k ± 0% -93.76% (p=0.000 n=20+20)
SanitizeBalances1000-8 162k ± 3% 9k ± 0% -94.40% (p=0.000 n=20+20)
```
The CPU profiles show the radical change as per
https://github.com/cosmos/cosmos-sdk/issues/7766#issuecomment-786671734
Later on, we shall do more profiling and fixes but for now this brings
down the run-time for InitGenesis.
Fixes#7766
Co-authored-by: Alessio Treglia <alessio@tendermint.com>
* change(bank): add utxo events and simplify logic
* add(bank): balance and supply tracking test
* chore(bank): fix balance tracking test comment
* fix(grpc): service test
* fix(bank): sub unlocked coins to use less gas
* fix(auth): cli test gas
* fix(rest): grpc gas test
* fix(staking/cli): increase delegation required gas
* add: burn events, fix tests
* fix(auth/tx): grpc test
* add(bank): coin events in delegate
* fix(bank): add amt check in delegate coins back
* change(bank): add coin spent and coin recv events in burn and mint
* change(bank): revert sub coin function
* change(auth): revert cli test
* change(auth): revert service test
* chore(auth): fix events comment in service_test.go
* chore: update CHANGELOG.md
* remove(bank): balanceError func
* chore(bank): address lint warnings
* chore(bank): update events spec
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Given that AccAddress is a []byte type, and its .String() method is
quite expensive, continuously invoking the method doesn't easily provide
a way for the result to be memoized. In memory profiles from
benchmarking OneBankSendTxPerBlock and run for a while, it showed >2GiB burnt
and SendCoins consuming a bunch of memory: >2GiB.
This change introduces a simple global cache with a map to intern
AccAddress values, so that we quickly look up the expensively computed
values. With it, the prior memory profiles are erased, and benchmarks
show improvements:
```shell
$ benchstat before.txt after.txt
name old time/op new time/op delta
OneBankSendTxPerBlock-8 1.94ms ± 9% 1.92ms ±11% -1.34% (p=0.011 n=58+57)
name old alloc/op new alloc/op delta
OneBankSendTxPerBlock-8 428kB ± 0% 365kB ± 0% -14.67% (p=0.000 n=58+54)
name old allocs/op new allocs/op delta
OneBankSendTxPerBlock-8 6.34k ± 0% 5.90k ± 0% -7.06% (p=0.000 n=58+57)
```
Fixes#8693
Co-authored-by: Alessio Treglia <alessio@tendermint.com>
