재욱 8428fd7c49 Keep the digit-separator feature off the default hot path ... PR #369's "performance-neutral" claim did not hold: the default (no-separator) parse was ~70% larger in the hot frame (parse_number_string inlined into from_chars: 833 -> 1414 x86/arm64 instructions), because 1. parse_number_string is force-inlined (always_inline), and the runtime dispatch inlined BOTH the has_separator==true and ==false instantiations into the default caller -- dragging the entire separator-aware scanner into the hot frame; and 2. the runtime separator branch survived in from_chars() even though a default-constructed parse_options provably has no separator, because the thin from_chars_caller forwarder was not inlined, so the compile-time '\0' was lost across the call boundary and the branch (plus two calls) could not be folded away. Fixes: * FASTFLOAT_NOINLINE + a cold parse_number_string_with_separator trampoline so the separator instantiation stays strictly out of line; the default caller only ever materializes the has_separator==false code. * Force-inline from_chars_caller::call (all three specializations) so the separator branch constant-folds away on the common from_chars() path. Net: the default hot frame returns to 844 instructions (vs 833 on main; the +11 is the unrelated parse_number_string refactor and is unchanged by this commit). The separator path is unaffected and all tests pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>		2026-06-21 11:27:39 +09:00
..
fast_float	Keep the digit-separator feature off the default hot path	2026-06-21 11:27:39 +09:00