There are several things we need to fix.
Since go 1.24 pereferable way to write benchmarks is to use b.Loop. We have a lot of benchmark functions which use b.N and some of them rely on b.N value which is incorrect.
Some benchmarks are just useless (take a look at node.BenchmarkCopy). We need to get rid of such benchmarks. Not just because they are useless but also some of them take a lot of time to execute (they are too fast and it takes time for testing package to figure out number of iterations to reach duration of 1 second).
Some of benchmarks are incorrect. For example, node.BenchmarkOr. Node size depends on b.N and therefore (on some laptops) such benchmarks never converge. Here is article by Dave Cheney (https://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go) - take a look at Traps for young players section. Also for some benchmarks (again node.BenchmarkCopy) compiler optimizes away all the code.
There are several things we need to fix.
Since go 1.24 pereferable way to write benchmarks is to use
b.Loop. We have a lot of benchmark functions which useb.Nand some of them rely onb.Nvalue which is incorrect.Some benchmarks are just useless (take a look at
node.BenchmarkCopy). We need to get rid of such benchmarks. Not just because they are useless but also some of them take a lot of time to execute (they are too fast and it takes time fortestingpackage to figure out number of iterations to reach duration of 1 second).Some of benchmarks are incorrect. For example,
node.BenchmarkOr. Node size depends onb.Nand therefore (on some laptops) such benchmarks never converge. Here is article by Dave Cheney (https://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go) - take a look atTraps for young playerssection. Also for some benchmarks (againnode.BenchmarkCopy) compiler optimizes away all the code.b.Loopeverywhere;b.N;