Skip to content
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: store/cachekv: Correct the naming and implementation for existing benchmarks #10116

Merged
merged 8 commits into from
Nov 10, 2021

Conversation

ValarDragon
Copy link
Contributor

@ValarDragon ValarDragon commented Sep 11, 2021

Description

Cref discussion in #10026, updates the CacheKV Benchmark naming and implementation to correspond to whats actually going on, and remove many irrelevant/incorrect components from being in the benchmarks timing.

Basically the old Benchmark's iterator creation was very flawed, and never hit the complex case, only repeatedly performing the best case performance of the iterator. Instead it really benchmarked iterator set and next operations.

This PR splits out the benchmarks for those two accordingly.


Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

  • included the correct type prefix in the PR title
  • added ! to the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • followed the guidelines for building modules
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md - N/A imo
  • included comments for documenting Go code
  • updated the relevant documentation or specification
  • reviewed "Files changed" and left comments if necessary
  • confirmed all CI checks have passed - lint failure unrelated

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

  • confirmed the correct type prefix in the PR title
  • confirmed ! in the type prefix if API or client breaking change
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage
  • manually tested (if applicable)

@orijbot
Copy link

orijbot commented Sep 11, 2021

@ValarDragon
Copy link
Contributor Author

Lint issues appear to be from master, not this PR

Copy link
Collaborator

@odeke-em odeke-em left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for this change @ValarDragon! A few things:

  • You aren't using b.N; this defeats the purpose of using the benchmarking suite which continually runs until the benchmark is run reliably enough -- this is a must for benchmarks run using -bench= otherwise we'd have to run the code ourselves
  • You aren't using keySize -- I presume that this PR is a work-in-progress?

store/cachekv/store_bench_test.go Outdated Show resolved Hide resolved
store/cachekv/store_bench_test.go Show resolved Hide resolved
store/cachekv/store_bench_test.go Outdated Show resolved Hide resolved
Comment on lines -43 to -47
func BenchmarkCacheKVStoreIterator500(b *testing.B) { benchmarkCacheKVStoreIterator(500, b) }
func BenchmarkCacheKVStoreIterator1000(b *testing.B) { benchmarkCacheKVStoreIterator(1000, b) }
func BenchmarkCacheKVStoreIterator10000(b *testing.B) { benchmarkCacheKVStoreIterator(10000, b) }
func BenchmarkCacheKVStoreIterator50000(b *testing.B) { benchmarkCacheKVStoreIterator(50000, b) }
func BenchmarkCacheKVStoreIterator100000(b *testing.B) { benchmarkCacheKVStoreIterator(100000, b) }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why aren't we testing with various sizes?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ValarDragon can you help get some of these open questions answered. I would like to merge this asap

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one was (intended to be) answered by the overall reply at the bottom.

The benchmarks atm are structured to do b.N of each operation, with then no further repetitions. At least for Next, this is expected to be a constant time operation / an operation whose size only depends on the parent cache, hence its consistent with the b.N behavior.

This was because the alternative to do things well, would be to make b.N separate, independent stores / independent parents, before starting the timer in order to ensure theres no weird loading with the data cache.

I think we could do size as a separate parameter, but I don't think this is blocking here personally.

store/cachekv/store_bench_test.go Outdated Show resolved Hide resolved
Comment on lines +60 to 62
for _, k := range keys {
kvstore.Set(k, value)
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are only running this benchmark once, that's definitely not a reliable way of getting appropriate runs.

Copy link
Contributor Author

@ValarDragon ValarDragon Sep 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean? Its doing b.N invocations of set, because thats the number of keys.

Unless the point is that a single set operation is too micro of an operation, and needs to be benchmarked in batches. (E.g. benchmarking the time for 10000 key set operations)

I think that'd make sense iff the goal was to measure growth of Set timing, as number of keys in the store grows.


iter := kvstore.Iterator(keys[0], keys[b.N])

for _ = iter.Key(); iter.Valid(); iter.Next() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unreliable benchmark; it'll only run say 32 times which defeats the purpose of using b.N .

Copy link
Contributor Author

@ValarDragon ValarDragon Sep 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean? Its making b.N calls to next, since its an iterator over b.N keys.

key := make([]byte, 32)
value := make([]byte, 32)
// Use a singleton for value, to not waste time computing it
value := randSlice(32)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We aren't using keysize but we should be.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thats for the value though, that doesn't matter there.

What would make more sense imo is hardcoding a value size much greater than expected keysize.

Copy link
Contributor Author

@ValarDragon ValarDragon Nov 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The value length is only important for cache lines / copying things on stack, so it could be a separate parameter if we want. A default is fine imo. I can change the value to be like 20kb.

I think were pretty far of from being worried about how things grow as value size grows or non-constant sizes. Don't want exponential numbers of benchmark instances, for configurations that aren't that important.

This PR wasn't intended to be profound, but to fix the definitely wrong benchmark naming / code from before, and split out the components to be improved versions of the things it subsumed from before.

store/cachekv/store_bench_test.go Outdated Show resolved Hide resolved
@ValarDragon
Copy link
Contributor Author

ValarDragon commented Sep 11, 2021

This is using b.N to setup the exact number of invocations for the hot loop. All the hot loops being measured are of size b.N. Additionally, key size is used for the sizes of the keys here?

Its not used for the size of the values, since that doesn't make sense

@codecov
Copy link

codecov bot commented Sep 13, 2021

Codecov Report

Merging #10116 (3480f38) into master (2394266) will decrease coverage by 0.09%.
The diff coverage is n/a.

❗ Current head 3480f38 differs from pull request most recent head 27d0a2c. Consider uploading reports for the commit 27d0a2c to get more accurate results
Impacted file tree graph

@@            Coverage Diff             @@
##           master   #10116      +/-   ##
==========================================
- Coverage   64.33%   64.24%   -0.10%     
==========================================
  Files         592      572      -20     
  Lines       56008    54230    -1778     
==========================================
- Hits        36034    34841    -1193     
+ Misses      17912    17408     -504     
+ Partials     2062     1981      -81     
Impacted Files Coverage Δ
x/distribution/simulation/operations.go 80.54% <0.00%> (-9.73%) ⬇️
x/mint/module.go 52.54% <0.00%> (-3.02%) ⬇️
types/module/module.go 65.04% <0.00%> (-1.96%) ⬇️
server/rosetta/client_online.go 0.00% <0.00%> (-1.71%) ⬇️
store/cachekv/store.go 77.63% <0.00%> (-1.32%) ⬇️
store/cachemulti/store.go 9.52% <0.00%> (-0.48%) ⬇️
crypto/keyring/legacy_info.go 61.95% <0.00%> (-0.41%) ⬇️
x/bank/keeper/keeper.go 71.72% <0.00%> (-0.39%) ⬇️
client/tx/tx.go 40.93% <0.00%> (-0.31%) ⬇️
x/auth/tx/builder.go 78.40% <0.00%> (-0.21%) ⬇️
... and 55 more

@odeke-em
Copy link
Collaborator

odeke-em commented Oct 8, 2021

@ValarDragon please rebase from the latest on master and apologies for the late replies.

@tac0turtle
Copy link
Member

tac0turtle commented Oct 11, 2021

@ValarDragon please rebase from the latest on master and apologies for the late replies.

@odeke-em could leave an approval when ready. Will help saying its ready

Copy link
Collaborator

@odeke-em odeke-em left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @ValarDragon and well done! Thank you @marbar3778 for the advocacy! Let's ship it, LGTM 🎉🪐

@tac0turtle tac0turtle added the A:automerge Automatically merge PR once all prerequisites pass. label Nov 10, 2021
@mergify mergify bot merged commit a9ea383 into master Nov 10, 2021
@mergify mergify bot deleted the dev/correct_cachekv_benchmarks branch November 10, 2021 16:20
fedekunze pushed a commit to tharsis/cosmos-sdk that referenced this pull request Nov 15, 2021
…ng benchmarks (cosmos#10116)

## Description

Cref discussion in cosmos#10026, updates the CacheKV Benchmark naming and implementation to correspond to whats actually going on, and remove many irrelevant/incorrect components from being in the benchmarks timing.

Basically the old Benchmark's iterator creation was very flawed, and never hit the complex case, only repeatedly performing the best case performance of the iterator. Instead it really benchmarked iterator set and next operations.

This PR splits out the benchmarks for those two accordingly.

---

### Author Checklist

*All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.*

I have...

- [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [x] added `!` to the type prefix if API or client breaking change
- [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting))
- [x] provided a link to the relevant issue or specification
- [x] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules)
- [x] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing)
- [x] added a changelog entry to `CHANGELOG.md` - N/A imo
- [x] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [x] updated the relevant documentation or specification
- [x] reviewed "Files changed" and left comments if necessary
- [x] confirmed all CI checks have passed - lint failure unrelated

### Reviewers Checklist

*All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.*

I have...

- [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [ ] confirmed `!` in the type prefix if API or client breaking change
- [ ] confirmed all author checklist items have been addressed 
- [ ] reviewed state machine logic
- [ ] reviewed API design and naming
- [ ] reviewed documentation is accurate
- [ ] reviewed tests and test coverage
- [ ] manually tested (if applicable)
fedekunze added a commit to tharsis/cosmos-sdk that referenced this pull request Nov 15, 2021
* IAVL

* perf: store/cachekv: Correct the naming and implementation for existing benchmarks (cosmos#10116)

## Description

Cref discussion in cosmos#10026, updates the CacheKV Benchmark naming and implementation to correspond to whats actually going on, and remove many irrelevant/incorrect components from being in the benchmarks timing.

Basically the old Benchmark's iterator creation was very flawed, and never hit the complex case, only repeatedly performing the best case performance of the iterator. Instead it really benchmarked iterator set and next operations.

This PR splits out the benchmarks for those two accordingly.

---

### Author Checklist

*All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.*

I have...

- [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [x] added `!` to the type prefix if API or client breaking change
- [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting))
- [x] provided a link to the relevant issue or specification
- [x] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules)
- [x] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing)
- [x] added a changelog entry to `CHANGELOG.md` - N/A imo
- [x] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [x] updated the relevant documentation or specification
- [x] reviewed "Files changed" and left comments if necessary
- [x] confirmed all CI checks have passed - lint failure unrelated

### Reviewers Checklist

*All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.*

I have...

- [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [ ] confirmed `!` in the type prefix if API or client breaking change
- [ ] confirmed all author checklist items have been addressed 
- [ ] reviewed state machine logic
- [ ] reviewed API design and naming
- [ ] reviewed documentation is accurate
- [ ] reviewed tests and test coverage
- [ ] manually tested (if applicable)

* store cosmos#10486

* supply cosmos#10393

* supply cosmos#10393

* telemetry cosmos#10334

* module account

Co-authored-by: Marko <[email protected]>
Co-authored-by: Dev Ojha <[email protected]>
Co-authored-by: Emmanuel T Odeke <[email protected]>
Co-authored-by: likhita-809 <[email protected]>
blewater pushed a commit to e-money/cosmos-sdk that referenced this pull request Dec 8, 2021
…ng benchmarks (cosmos#10116)

## Description

Cref discussion in cosmos#10026, updates the CacheKV Benchmark naming and implementation to correspond to whats actually going on, and remove many irrelevant/incorrect components from being in the benchmarks timing.

Basically the old Benchmark's iterator creation was very flawed, and never hit the complex case, only repeatedly performing the best case performance of the iterator. Instead it really benchmarked iterator set and next operations.

This PR splits out the benchmarks for those two accordingly.

---

### Author Checklist

*All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.*

I have...

- [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [x] added `!` to the type prefix if API or client breaking change
- [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting))
- [x] provided a link to the relevant issue or specification
- [x] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules)
- [x] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing)
- [x] added a changelog entry to `CHANGELOG.md` - N/A imo
- [x] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [x] updated the relevant documentation or specification
- [x] reviewed "Files changed" and left comments if necessary
- [x] confirmed all CI checks have passed - lint failure unrelated

### Reviewers Checklist

*All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.*

I have...

- [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [ ] confirmed `!` in the type prefix if API or client breaking change
- [ ] confirmed all author checklist items have been addressed 
- [ ] reviewed state machine logic
- [ ] reviewed API design and naming
- [ ] reviewed documentation is accurate
- [ ] reviewed tests and test coverage
- [ ] manually tested (if applicable)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A:automerge Automatically merge PR once all prerequisites pass.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants