Float parsing speed and allocation regressions 2.8.1->2.8.2->2.8.5. Up to 16x slower

[jaakkor2]

using Parsers
using BenchmarkTools
@btime Parsers.parse(Float64, "1.23e-4")

Version	Btime
v2.8.1	15.045 ns (0 allocations: 0 bytes)
v2.8.2	43.219 ns (0 allocations: 0 bytes)
v2.8.4	49.748 ns (0 allocations: 0 bytes)
v2.8.5	253.235 ns (9 allocations: 304 bytes)

Measurements with

julia> versioninfo()
Julia Version 1.12.6
Commit 15346901f0 (2026-04-09 19:20 UTC)
Build Info:
  Official https://julialang.org release
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: 20 × 13th Gen Intel(R) Core(TM) i7-1370P
  WORD_SIZE: 64
  LLVM: libLLVM-18.1.7 (ORCJIT, alderlake)
  GC: Built with stock GC
Threads: 20 default, 1 interactive, 20 GC (on 20 virtual cores)

[KristofferC]

Bot says:

---

v2.8.4 → v2.8.5 (50ns → 253ns + 9 allocations): PR #204 (0e3226e, "reduce parser precompile workload"). It
wrapped the rare integer-widening paths in Base.inferencebarrier(_widen(digits)) at four sites in src/floats.jl
so precompiling Float64 wouldn't eagerly infer the UInt128/BigInt overflow tree. The problem is where the
barriers sit:

• The worst one was a conditional assignment in the hot path of parsedigits: (overflows(IntType) && ...) &&
  (digits = Base.inferencebarrier(_widen(digits))). After that branch merges, inference must type digits as Any,
  so the unconditional parsefrac call on the very next line becomes a dynamic dispatch with boxed arguments — for
  every float parsed, even though the overflow branch is never taken for "1.23e-4". That's the 9 allocations.
• The other three sites are return _parsedigits(...) style calls. Because one argument is Any, the call is
  dynamic and inferred as Any, which taints the return type of parsedigits/parsefrac/parseexp to Any and
  propagates instability up the whole chain. The ::Tuple{...} assertions inside the @noinline helpers don't help,
  because they're inside the callee — the call site still sees Any.

v2.8.1 → v2.8.2 (15ns → 43ns): PR #196 (57ae5c7, "Mark Inf/-Inf as special value"). I bisected it to exactly
this commit (12.7ns → 39.2ns on my machine). The Inf/-Inf logic itself is trivial — the regression comes from
the bundled removal of @inline / Base.@_inline_meta from the entire float pipeline (typeparser, parsedigits,
parsefrac, parseexp, scale, noscale, two_prod, and the component closures), so the layered parser no longer
flattens into one function.

[KristofferC]

#206