The performance is very competitive and considering how small it is, it could be better on balance in large systems, if it occupies less i-cache. But, that would depend on whether its binary representation is small in proportion to its source representation.
Schubfach's table is quite large compared to some alternatives with similar performance characteristics. swiftDtoa's code and tables combined are smaller than just Schubfach's table in the linked implementation. Ryu and Dragonbox are larger than swiftDtoa, but also use smaller tables than Schubfach, IIRC.
If I$ is all you care about, then table size may not matter, but for constrained systems, other algorithms in general, and swiftDtoa in particular, may be better choices.
The performance is very competitive and considering how small it is, it could be better on balance in large systems, if it occupies less i-cache. But, that would depend on whether its binary representation is small in proportion to its source representation.
Tables are ~10k but it's possible to compress them to hundreds of bytes using the method from the Dragonbox paper (https://github.com/fmtlib/fmt/blob/a6e871e39b835e5f87c5f5627...) at the cost of some performance.
Schubfach's table is quite large compared to some alternatives with similar performance characteristics. swiftDtoa's code and tables combined are smaller than just Schubfach's table in the linked implementation. Ryu and Dragonbox are larger than swiftDtoa, but also use smaller tables than Schubfach, IIRC.
If I$ is all you care about, then table size may not matter, but for constrained systems, other algorithms in general, and swiftDtoa in particular, may be better choices.