This repository has been archived by the owner on Apr 4, 2024. It is now read-only.
x/evm: (*Keeper).EthereumTx should use make(T, len) instead of make(T, 0) #825
Comments
odeke-em
added a commit
that referenced
this issue
Dec 12, 2021
…x.Logs
Uses the fastest slice making idiom of creating the well known
size of a slice using
make([]sdk.Attribute, len(response.Logs))
for i, log := range response.Logs {
txLogAttrs[i] = ...
}
instead of
make([]sdk.Attribute, 0)
for _, log := range response.Logs {
txLogAttrs = append(txLogAttrs, ...)
}
which had a few problems:
1. Using 0 for size then appending is quite slow yet we know the exact size
2. Using append instead of indexing is slower
If we examine the advisory at https://bencher.orijtech.com/perfclinic/sliceupdate/
and the verdict at https://bencher.orijtech.com/perfclinic/sliceupdate/#verdict
this new scheme shows a massive improvement in that call site.
Fixes #825
odeke-em
added a commit
that referenced
this issue
Dec 14, 2021
…x.Logs
Uses the fastest slice making idiom of creating the well known
size of a slice using
make([]sdk.Attribute, len(response.Logs))
for i, log := range response.Logs {
txLogAttrs[i] = ...
}
instead of
make([]sdk.Attribute, 0)
for _, log := range response.Logs {
txLogAttrs = append(txLogAttrs, ...)
}
which had a few problems:
1. Using 0 for size then appending is quite slow yet we know the exact size
2. Using append instead of indexing is slower
If we examine the advisory at https://bencher.orijtech.com/perfclinic/sliceupdate/
and the verdict at https://bencher.orijtech.com/perfclinic/sliceupdate/#verdict
this new scheme shows a massive improvement in that call site.
Fixes #825
odeke-em
added a commit
that referenced
this issue
Dec 14, 2021
…x.Logs (#827) Uses the fastest slice making idiom of creating the well known size of a slice using make([]sdk.Attribute, len(response.Logs)) for i, log := range response.Logs { txLogAttrs[i] = ... } instead of make([]sdk.Attribute, 0) for _, log := range response.Logs { txLogAttrs = append(txLogAttrs, ...) } which had a few problems: 1. Using 0 for size then appending is quite slow yet we know the exact size 2. Using append instead of indexing is slower If we examine the advisory at https://bencher.orijtech.com/perfclinic/sliceupdate/ and the verdict at https://bencher.orijtech.com/perfclinic/sliceupdate/#verdict this new scheme shows a massive improvement in that call site. Fixes #825
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Noticed while auditing code on the hunt for higher TPS, this code https://github.com/tharsis/ethermint/blob/54fa882ab8e56e3de65a1a730b02e73884c26bed/x/evm/keeper/msg_server.go#L55-L62
but if we examine perfclinic's verdict per https://bencher.orijtech.com/perfclinic/sliceupdate/#verdict and per https://bencher.orijtech.com/perfclinic/sliceupdate/#make-with-size-n-capacity-n
We should use an index with the size for that slice.
The text was updated successfully, but these errors were encountered: