Troubleshooting

This is a collection of some specific problems and their solutions when working with Hana. These issues lie within the realm of the compilers and are thus not solvable from a library point of view, at least not for now.

Executable sizes are huge when using Hana's containers (Clang LTO)

Problem: After linking several object files into one executable, the size of the executable is huge, although the compiler seems to have done its job and computed everything at compile-time.

Reason: It appears that Clang has difficulties or fails to remove external symbol names from object files and executables, even when not compiling with debug information. And since the most of the compile-time data is encapsulated in the type system -- as intended and as it is the very purpose of Hana -- these may become huge when working with large amounts of data in compile-time containers like hana::tuple or hana::map. Hence, and since those symbols are external, the compiler isn't able to remove them in a single translation unit. The same accounts for strip. The problem thus lies in the linking process.

Solution: Link your executable with link time optimization enabled (-flto for Clang and GCC) and invoke strip afterwards to remove unused symbol names.

References: See #197 for the whole story.

Sizes of empty structs and classes are unexpected large (Clang-cl EBO)

Problem: When compiling with MSVC compatiblility mode enabled Clang-cl and comparing against a regular Clang compiled binary, the sizes of empty structs and of structs inheriting empty structs are increased.

Reason: It's a feature, not a bug, or more of an emulated shortcoming rather than a real bug. MSVC is applying empty base optimization in a rather limited fashion. Only the first inherited empty base class appears to be optimized away, but none of the following. Accordingly, the size increases when inheriting from several empty bases. Unfortunately, Hana makes use of empty base classes for its tag dispatching system. Finally, since Clang-cl emulates MS's cl to be able to parse the MS standard C++ library and to be binary compatible, it must emulate that shortcoming.

Solution: Sorry, no solution unless you're restricted to use Clang-cl. Consider switching to a regular Clang.

References: See #201 and Stackoverflow