Monomorphized Generics vs Concrete Type Specialization for Binary Size

Direct Answer

Crystal does not provide a compiler flag or language feature to suppress monomorphization for specific type instantiations. Every concrete type used with a generic type or method gets a distinct copy of the generated machine code. There is no equivalent of C++ extern template or Rust dyn Trait / shared generics.

The only way to reduce the number of instantiations is to change the design so that fewer concrete types flow through generic code paths. The practical levers are indirect:

• Replace a generic type parameter with an abstract base class or module and use virtual dispatch.
• Use a Union of the concrete types you actually need.
• Box values with Box(T) (heap allocation, single code path).
• In unsafe contexts, erase to Pointer(Void) and cast manually.

Each approach collapses many instantiations into one at the cost of runtime indirection.

Compiler Flags That Affect Final Artifact Size

These flags change the total binary size but do not limit per-type specialization:

• --no-debug — drops DWARF debug information.
• --release — enables LLVM optimizations; can grow or shrink the binary depending on inlining/unrolling decisions.
• --single-module — emits one LLVM module, enabling better cross-instantiation dead-code elimination and inlining. Warning: significantly increases compiler memory usage and may slow compilation.
• --link-flags "-s" — strips symbols at link time (removes stack traces).

Annotations @[NoInline] and @[AlwaysInline] influence inlining only; they do not reduce the number of generated instantiations. Compile-time -D/--define flags can conditionally exclude whole code paths, indirectly removing instantiations for optional features.

Primary Indicators to Switch from Generic Polymorphism to Concrete Definitions

Move to a concrete or virtual-dispatch design when you observe:

1. Binary size growing faster than source size — each new type instantiation adds a non-trivial symbol.
2. nm --size-sort -C (or llvm-nm) shows clusters of near-identical symbols differing only in mangled type suffixes.
3. Compile time and compiler memory grow superlinearly as you add more type instantiations.
4. A generic is instantiated for many types but only a few are hot paths (profile-guided).

There is no universal threshold. A workable heuristic: if a generic is instantiated for more than a handful of types, each instantiation contributes a measurable symbol, and profiling shows the generic path is not the bottleneck, replace it with a concrete or virtual-dispatch design and re-measure.

Verification Steps

1. Build the same source with default, --release, --release --no-debug, and --release --no-debug --single-module; record output size and use --stats to capture compile time and memory for each.
2. Run nm --size-sort -C (or llvm-nm) on the binary to list the largest symbols and look for clusters of near-identical names differing only in type suffixes.
3. Use size -A or llvm-size to break the artifact into sections and confirm whether code (.text) rather than data or debug sections dominates growth.
4. Use crystal tool expand to inspect macro-generated instantiations and --emit llvm-ir to see how many specialized functions were actually generated.
5. Check crystal --version and crystal build --help on the target machine to confirm which flags and defaults apply to your compiler release before drawing conclusions.

One Missing Diagnostic Detail

What is the approximate number of distinct concrete types that currently instantiate your hottest generic type(s)? This number determines whether the design change will yield measurable binary-size reduction.