I think you have created rather a lot of threads recently on exactly the same topic: https://groups.google.com/g/golang-nuts/search?q=tapi%20benchmark
I'm not convinced that another one is needed. There have been good answers in the previous threads. Go has a fairly complex runtime (as you'll see from the size of compiling "Hello world"), and such boundary conditions are to be expected, especially when looking at memory allocation. But these rarely matter in real-world programs. If they do matter in your application, then you may be happier with a language like C, where the machine-code generated maps more directly to the code you write. Even then, you will come across oddities in the microarchitectures of the underlying hardware, such as what happens when caches are under eviction pressure. When I was programming 6800's and 6502's, I was able to work out exactly how long a piece of code would take to run, by generating a cycle-by-cycle count. That's not possible any more :-) On Wednesday, 28 July 2021 at 15:43:38 UTC+1 tapi...@gmail.com wrote: > > The benchmark code: https://play.golang.org/p/IqVnVa5x9qp > > When N == 16384, the benchmark result: > > Benchmark_Insert-4 134622 8032 ns/op 32768 B/op > 1 allocs/op > Benchmark_Insert2-4 132049 8201 ns/op 32768 B/op > 1 allocs/op > > When N == 16385, the benchmark result: > > Benchmark_Insert-4 118677 9374 ns/op 40960 B/op > 1 allocs/op > Benchmark_Insert2-4 136845 7744 ns/op 40960 B/op > 1 allocs/op > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e411eac8-3b08-47b0-92a4-be09d960f67en%40googlegroups.com.
