Wise people know to avoid micro-benchmarks, but this is not a even micro-benchmark, it's a nano-benchmark.... Testing isolated things like empty loops or ...a

Wise people know to avoid micro-benchmarks, but this is not a even micro-benchmark, it's a nano-benchmark.... Testing isolated things like empty loops or ...a single assignment. Those really don't make sense for modern compilers. The dead giveaway is having to modify your code in weird ways, so you don't trigger dead code elimination. If you trigger dead code elimination it means you code isn't producing anything, and you're benchmarking various edge cases that won't occur in the real world. You need to at least implement a simple algorithm or some small unit of functionality that makes sense in a real program. Swift's compiler is designed to aggressively inline and remove reference counting overhead in cohesive units of code, however if you test everything statement by statement, then whether you enable optimization or not, it can't optimize that much. That said I don't mind the article. It might help Apple discover places where Swift might be made even faster.