Improve compile time

[ncihnegn]

For the same options, CLI11 triples my compile time of boost::program_options.

[henryiii]

boost::program_options is not a header-only library - it is pre-compiled. The benefit of not having to pre-compile the library comes at a compile time cost, as with all header only libraries. However, you can mitigate that by making sure the CLI11 code only is in one cpp file, and keeping your components separate. There's no need to include CLI11 in any other file - you can just use plain C++ types! That's part of the design. PyBind11 has some excellent examples of how to keep headers leaking into other files, for maximum compile-time performance.

However, CLI11 still only takes a couple of seconds to compile, so do you have a very simple application? It should not grow as your application becomes more complex.

[henryiii]

Technically, CLI11's current design would allow it to have an optional precompiled mode - I think a (very) few other libraries support a dual usage mode. However, it may become more heavily templated in 2.0, with Option<T> instead of the current Option. If that happens, it will need to remain header only (since templates cannot be precompiled).

[henryiii]

To support precompilation, all headers would need to be split into two, a declaration and an implementation, then there would be a way to precompile the implementation files optionally.

Personally, though, if I have to do it, I'll wait till both the redesign, and until C++ Modules become finalized, probably C++20, hopefully not C++23.

[ncihnegn]

I agree. But it will be nice if there is a macro like FAST_COMPILE to exclude some codes.

[henryiii]

I wonder if something like this would help: https://quuxplusone.github.io/blog/2019/01/06/hyper-function/ - CLI11 uses std::function everywhere. Would have to be re-implemented or permission to use it in a BSD software would be needed, but would be interesting to test.

There really aren't many optional codes in CLI11. The only one is Timer, and you don't get it unless you include it. In general, you should only includes CLI11 is a limited set of files, probably only your main file.

[henryiii]

I'm planning to move the extra transforms and any other less heavily used optional portions to a separate file, that will close this issue when done.

[jlisee]

Dual mode is definitely the way to go here. Take a look at fmt for a library so good that it basically went into the standard library. It has an expressive API but the core is not templates so users still have a very productive compile time cycle. For example do you really need to support every type or could Option<T> really just have a variant? And maybe you have an optional template API that allows more user flexibility.

The slow compile time of this library is a big reason we are considering dropping it from our project or doing a re-write/fork so we can become productive again. It just makes no sense to wait 10+ seconds for a simple command line application to compile.

[henryiii]

10 seconds doesn't seem that bad just for one command line program; you should only be including and using CLI11 from one file only. The entire test suite and examples, with 38 executables, takes 2.8 minutes to compile, or 4.4 seconds each (Dual core machine, however).

The library actually avoids templates for the most part. Only option additions are templates; all types are non-templated (CLI::app instead of CLI::app<>, CLI::option, etc.). It would be fairly trivial to separate the files into ".hpp" and ".inl" files, and then optionally compile the ".inl" files - almost everything could be precompiled. It would have to be done in such a way, however, that normal users of the header only library could continue to use it. I believe 90% of the library could be pre-compiled with the current API, maybe more.

If you are serious about rewriting/forking, I'd happily help with a PR to do that in the way I described above for 1.9 or 2.0. A CMake user should get the precompiling for free, and users of header only without CMake should not even notice.

[henryiii]

Note: Including boost::optional (I think) seems to change a ~3-4 minute total compile into a 20 minute compile on CI! This should be investigated, and made non-automatic if it can't be fixed. I think Boost::Optional pulls in a lot of legacy pre-C++11 headers from Boost. @jlisee, could you retry with CLI11_BOOST_OPTIONAL explicitly defined to 0? You might see 4x or more compile time improvement, if I'm right.

[henryiii]

I'm looking at the Azure build times, for reference. The GCC 9 docker build takes 2.5 minutes. The GCC 4.7 docker build takes 1.5 minutes. The native builds also do the single header mode, but on macOS and Linux it just doubles the build time (since it builds twice, in effect). However, the native Linux build (only change I can think of is Boost and Boost::Optional) takes 10-20 minutes!