aarifullin/neoneo-go
1
0
Fork 0
forked from TrueCloudLab/neoneo-go
Code Pull requests Activity
neoneo-go/pkg/encoding/bigint/bench_test.go

18 lines
288 B
Go
Raw Permalink Normal View History

bigint: don't allocate in ToPreallocatedBytes Turns out, it's almost always allocating because we're mostly dealing with small integers while the buffer size is calculated in 8-byte chunks here, so preallocated buffer is always insufficient. name old time/op new time/op delta ToPreallocatedBytes-8 28.5ns ± 7% 19.7ns ± 5% -30.72% (p=0.000 n=10+10) name old alloc/op new alloc/op delta ToPreallocatedBytes-8 16.0B ± 0% 0.0B -100.00% (p=0.000 n=10+10) name old allocs/op new allocs/op delta ToPreallocatedBytes-8 1.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10) Fix StorageItem reuse at the same time. We don't copy when getting values from the storage, but we don when we're putting them, so buffer reuse could corrupt old values.
2022-05-31 20:10:56 +00:00
package bigint
import (
"math/big"
"testing"
)
func BenchmarkToPreallocatedBytes(b *testing.B) {
v := big.NewInt(100500)
bigint: don't reallocate big.Int in ToBytes(), fix #2864 In some cases n.Add() can reuse the []Word buffer and n.Sub() reallocate it away. If that happens, we're out of luck with 0.99.0+ versions (since 3945e8185773c1001ad698f94271a082260aacbe). I'm not sure why it does that, bit width doesn't change in most of the cases and even if it does, we still have enough of it in cap() to hold the old Abs() value (when we have a negative value we in fact decreate its Abs() first and increase it back afterwards). Still, that's what we have. So when we have processTokenTransfer() doing Neg/Neg in-place its value is not affected, but the original []Word bits that are reused by amount value are (they're shared initially, Amount: *amount). name old time/op new time/op delta ToPreallocatedBytes-8 65.8ns ± 2% 45.6ns ± 2% -30.73% (p=0.008 n=5+5) name old alloc/op new alloc/op delta ToPreallocatedBytes-8 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta ToPreallocatedBytes-8 0.00 0.00 ~ (all equal)
2023-01-10 18:40:15 +00:00
vn := big.NewInt(-100500)
bigint: don't allocate in ToPreallocatedBytes Turns out, it's almost always allocating because we're mostly dealing with small integers while the buffer size is calculated in 8-byte chunks here, so preallocated buffer is always insufficient. name old time/op new time/op delta ToPreallocatedBytes-8 28.5ns ± 7% 19.7ns ± 5% -30.72% (p=0.000 n=10+10) name old alloc/op new alloc/op delta ToPreallocatedBytes-8 16.0B ± 0% 0.0B -100.00% (p=0.000 n=10+10) name old allocs/op new allocs/op delta ToPreallocatedBytes-8 1.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10) Fix StorageItem reuse at the same time. We don't copy when getting values from the storage, but we don when we're putting them, so buffer reuse could corrupt old values.
2022-05-31 20:10:56 +00:00
buf := make([]byte, 4)
for i := 0; i < b.N; i++ {
_ = ToPreallocatedBytes(v, buf[:0])
bigint: don't reallocate big.Int in ToBytes(), fix #2864 In some cases n.Add() can reuse the []Word buffer and n.Sub() reallocate it away. If that happens, we're out of luck with 0.99.0+ versions (since 3945e8185773c1001ad698f94271a082260aacbe). I'm not sure why it does that, bit width doesn't change in most of the cases and even if it does, we still have enough of it in cap() to hold the old Abs() value (when we have a negative value we in fact decreate its Abs() first and increase it back afterwards). Still, that's what we have. So when we have processTokenTransfer() doing Neg/Neg in-place its value is not affected, but the original []Word bits that are reused by amount value are (they're shared initially, Amount: *amount). name old time/op new time/op delta ToPreallocatedBytes-8 65.8ns ± 2% 45.6ns ± 2% -30.73% (p=0.008 n=5+5) name old alloc/op new alloc/op delta ToPreallocatedBytes-8 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta ToPreallocatedBytes-8 0.00 0.00 ~ (all equal)
2023-01-10 18:40:15 +00:00
_ = ToPreallocatedBytes(vn, buf[:0])
bigint: don't allocate in ToPreallocatedBytes Turns out, it's almost always allocating because we're mostly dealing with small integers while the buffer size is calculated in 8-byte chunks here, so preallocated buffer is always insufficient. name old time/op new time/op delta ToPreallocatedBytes-8 28.5ns ± 7% 19.7ns ± 5% -30.72% (p=0.000 n=10+10) name old alloc/op new alloc/op delta ToPreallocatedBytes-8 16.0B ± 0% 0.0B -100.00% (p=0.000 n=10+10) name old allocs/op new allocs/op delta ToPreallocatedBytes-8 1.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10) Fix StorageItem reuse at the same time. We don't copy when getting values from the storage, but we don when we're putting them, so buffer reuse could corrupt old values.
2022-05-31 20:10:56 +00:00
}
}
Copy permalink