The rust one claims around 3GB/s

https://codegolf.stackexchange.com/a/217455

You can take this much further! I think throughput is a great way to measure it.

Things like pre-allocation, no branching, constants, simd, etc

Also I think that CPU pining could help in this context but perhaps I need to check the code in my machine first.

If you're going idiomatic rust, then you might instead output a type that has a display impl rather than generating code that writes to stdout.

But what is the point? Why do you want to optimize the display? If you want to be able to fizz-buzz for millions of numbers, then you want to... Well realistically only compute them just before they are displayed.

1. `stdout().lock()` and `writeln!()` to that. By default using `print*!()` will write to `stdout()` which takes a process-wide lock each time. (Funnily enough they use .lock() in the "build up a buffer of the whole output" section, just to do one .write_all() call, which is the one time they don't need to use .lock() because Stdout's impl of write_all() will only take the lock once anyway.)

2. Wrap the locked stdout in a `BufWriter` and `writeln!()` to that. It won't flush on every line, but it also won't buffer the entire output, so it's a middle point between speed and memory usage.

---

For the final proc macro approach, there is the option to unroll the loop in the generated code, and the option to generate a &'static str literal of the output.

Despite writing things in scheme I ended up being the fastest. It is no magic bullet, but if you only want the regular fizz buzz it is a simple way to just about double the speed.

Yes it is a single instruction, but that is not indicative of the actual performance. Modulo on x86 is done through the div instruction which takes tens of cycles. When you compile the code you'll likely see a multiply + shift instead because you modulo by a constant.