Efficient C++: The hidden compile-time cost of auto return types
Efficient C++: The hidden compile-time cost of auto return types
andreasfertig.com
Efficient C++: The hidden compile-time cost of auto return types
13 comments
-
-
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
clangmight 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
intBenchmark 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
autoBenchmark 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 - With
-
If a function body is expensive to parse, isn't it then a complex function body that shouldn't go into the header anyways?
-
13 comments
Why the fuck do people do this to themselves.
From my discussion with C++ folk, auto is just part of the "modern" way of doing c++. Paired with the -> return type. Perhaps including that -> return type negates this problem? It's still strange to me. Feels more like Rust
Clean code, and compile-time is irrelevant for most projects.