Parse a long input once instead of twice

[Algunenano]

A mantissa of more than 19 significant digits needs more than 19 characters, so only a longer input can come back too_many_digits. Today that is discovered after a full parse without spans, and the input is then parsed a second time with them, in parse_number_slow_path. Testing the length up front sends it straight to the parse that materializes the spans, so it is parsed once.

This comes out of a round of profiling from_chars in ClickHouse, which parses floats from text for every row of a text format. We have a local helper that does this, parsing once with the spans materialized for inputs known to be long, though our own dispatch reaches it rarely. Of the float-parsing changes we ended up carrying, this is the one that also helps the library's own benchmark datasets, which is why it is the one being proposed.

The change is eight lines and does not touch the common path: the length test is under fastfloat_unlikely, and the parse below still gets the literal store_spans = false it had, which is what lets the force-inlined parser drop the span stores entirely.

Measurements

benchmarks/benchmark.cpp on an Intel Xeon 6975P-C (Granite Rapids) with clang 22.1.8, cycles per float, best of 5. canada and mesh are the repository's own datasets, the rest are 50k-line sets chosen to hit one path each.

	canada	mesh	round-trip doubles	short decimals	small integers
before	47.30	26.20	43.94	31.09	27.00
after	46.90	25.68	43.84	31.90	26.93

	long fractions	20-38 digit integers	>38 digit integers	long leading zeros
before	233.94	259.73	447.73	125.21
after	195.68	181.65	273.11	126.34

Results are bit-identical to main (value, errc and consumed length, for both double and float) over 400k adversarial inputs: 1 to 84 digit integers, long fractions, leading zeros, explicit exponents, and %.17g of random bit patterns. ctest passes with clang 22 and with gcc in C++20 mode.

The trade-off

The test looks at the range, not at the number. A caller that hands from_chars the whole remaining buffer for a short value will take the slow path on every value: measured at 20% for 7-character numbers in a large buffer (9.31 to 11.08 ns per value), against 6% faster when the range is tight (8.09 to 7.59 ns).

I tried deciding on the token instead, with a probe loop that counts mantissa characters one at a time, up to twenty, before committing. It costs more than the second parse it avoids: long fractions went to 258 cycles per float, worse than doing nothing. That is a result about that particular probe, though, not about token classification in general. ClickHouse classifies the token as well, but with a SWAR scan that consumes eight digits per iteration and bails out as soon as it sees ., e or E, and there it pays for itself. I have not tried a SWAR probe here, so this trade-off may be removable. Happy to do that, or to drop or gate the change, whichever you prefer.

Two fast paths ClickHouse keeps but that do not belong here

ClickHouse has two more float-parsing fast paths that I am deliberately not proposing. They work there because its dispatch already knows the token length and routes by shape, so each one only runs on the inputs it suits. Inside the library the choice would have to be made blind, and then each one wins on one shape and loses on the rest:

• An exact unsigned __int128 path for plain integers of at most 38 digits. 27% better on exactly that shape, 7 to 16% worse on every other long input, because of the extra scan needed to recognise it. Placed before digit_comp instead of in front of the parse it does nothing at all, since the mantissa versus mantissa + 1 disambiguation already resolves those inputs.
• Counting rather than accumulating digits past the nineteenth significant one. 21% better on integers over 38 digits, but splitting the integer scan into two loops costs 13% on mesh and on small integers.

This touches the same function as #410, so whichever lands second needs a trivial rebase.

[lemire]

@Algunenano Why is ClickHouse parsing these numbers with > 19 digits ? What is the application? What system is producing these outputs?

[Algunenano]

I can't really tell for sure, since the original optimizations for long integers are quite ancient (as in v1.1 or v21.1) but my guess is that it's related to the fact that we use float parsing to parse any number by default. This includes SQL text (I hope to change that soon) but also any input format where we infer the type. If you use our long integer types, (U)Int128/256, dump them into a CSV and read them back we'll read them as Float64 unless you explicitly pass the schema.

I can also share how I got to the need for this optimization: ClickHouse has 2 ways of parsing floating points: "fast" and "precise". Fast used to be the default and it was faster at the cost of some imprecisions (few ULPs at worst), which means every so often somebody would complain about it. Recently we introduced Darwin in the CI and, among many bugs and missing features, I noticed that the "fast" implementation was even more imprecise in Darwin ARM because it relied on long double being 80+ bits (it's 64 bits in that architecture).

I tested emulating the extra precision which lead to the "fast" mode to be both imprecise and slower, so instead I analyzed each case where "fast" was faster than "precise" and came up with ways to address this. This allowed me to change the default to the precise mode (backed by fast_float) so now all float parsing is both precise and faster than "fast". Final performance comparison of the mode change here

[lemire]

Ok. Let us investigate.

[lemire]

So I am not too excited about this PR. Here are the results I get (Intel Xeon Gold 6548N, random uint64_t values).

So you improve by 10% the perf on an unusual case, but it comes with a 3% penalty on more realistic inputs.

You refer in your PR message to inputs with dozens of digits or to people who serialize uint128 or uint256 and then parse them back as floats.

This looks to be like an unrealistic benchmark.

Can you point me at a realistic ClickHouse workload implying this type of processing?

[Algunenano]

This looks to be like an unrealistic benchmark.

I agree, even more considering it comes from a bad use (deserializing with the wrong type).

We have performance tests for these cases, but they aren’t representative of a specific workload; just something that somebody decided to speed up and test.

It’s more than fine to close the PR. If I find more general improvements or a specific use case where having a different hot path I’ll send them in.

Thanks a lot for considering and all the work you do

[lemire]

We do invite contributions. Thanks for the PR.