This is interesting, but drawing conclusions from only two measurements is not reasonable. Especially so when the time-span measured is in the order of a few ms. For example, the two instances of clang might not be running at the same clock frequency, which could easily explain away the observed difference.

Plus, you could easily generate a very large number of functions, to increase the amount of work the compiler has to do. So I did just that (N = 10,000), using the function from the article, and used hyperfine to perform the actual benchmarking.

• With int

  Benchmark 1: clang -o /dev/null test.cpp -c
    Time (mean ± σ):      1.243 s ±  0.018 s    [User: 1.192 s, System: 0.050 s]
    Range (min … max):    1.221 s …  1.284 s    10 runs
  

• With auto

  Benchmark 1: clang -o /dev/null test.cpp -c
    Time (mean ± σ):      1.291 s ±  0.015 s    [User: 1.238 s, System: 0.051 s]
    Range (min … max):    1.274 s …  1.320 s    10 runs
  

So if you have a file with 10'000 simple functions with/without auto, then it increases your compile time by ~4%.

I'd worry more about the readability of auto, than about the compile time cost at that point

Summary

If you want fast compile times, be careful with functions using auto as a return type in header files.

If a function body is expensive to parse, isn't it then a complex function body that shouldn't go into the header anyways?