Re: [go-nuts] Benchmark "overall" operation

> The usual way is to factor out any parts that can skew the results > before the benchmark loop and call b.ResetTimer() just before entering > the 'for i := 0; i < b.N; i++ {' loop. That isn’t applicable here. It is the performing of the operation that gets progressively slower. So when comparin

Re: [go-nuts] Benchmark "overall" operation

On Mon, Jul 8, 2024 at 10:36 PM Robert Engels wrote: > Is there anyway to do what I want? The usual way is to factor out any parts that can skew the results before the benchmark loop and call b.ResetTimer() just before entering the 'for i := 0; i < b.N; i++ {' loop. > If not, maybe a useful add

Re: [go-nuts] Benchmark "overall" operation

Understood. Is there anyway to do what I want? If not, maybe a useful addition, see https://javadoc.io/doc/org.openjdk.jmh/jmh-core/latest/org/openjdk/jmh/annotations/OperationsPerInvocation.html

Re: [go-nuts] Benchmark "overall" operation

On Mon, Jul 8, 2024 at 10:08 PM 'Robert Engels' via golang-nuts wrote: > Given this code (which I know is not “correct”): Setting b.N in the benchmark code has no specified behavior. The actual behavior at the moment ignores such changes. The algorithm used by the testing package adjusts b.N in

Re: [go-nuts] Benchmark "overall" operation

Actually, if I add b.Log("time per op",float64(b.Elapsed().Microseconds())/float64(N_ORDERS*2)) I get a different value than what benchmark reports, so I am certain setting b.N is not correct. > On Jul 8, 2024, at 3:08 PM, 'Robert Engels' via golang-nuts > wrote: > > Given this code (whi

[go-nuts] Benchmark "overall" operation

Given this code (which I know is not “correct”): func BenchmarkOrders(b *testing.B) { var ob = orderBook{} var inst = Equity{} var ex = testExchangeClient{} const N_ORDERS = 100 b.ResetTimer() b.N = N_ORDERS for i:=0;ihttps://groups.google.com/d/msgid/golang-nut