perf: speed up high-precision parsing

[Colerar]

Main change

The parser previously scanned fractional digits twice:

1. A forward pass, validated the entire numeric input and located the decimal point.
2. A reverse pass, converted the fractional digits into bytes.

This change stops the forward pass as soon as it reaches the decimal point. The rev pass now also validates characters.

Benchmark

run on my M5 Pro (6 S, 12 P)

diff (vs 8580293):

Case	Before median	After median	Diff	Change
high-precision-binary	114.500 ns	58.510 ns	−55.990 ns	−48.9%
high-precision-decimal	28.910 ns	16.910 ns	−12.000 ns	−41.5%
small-fraction	6.779 ns	5.314 ns	−1.465 ns	−21.6%
fraction	5.111 ns	4.337 ns	−0.774 ns	−15.1%
grouped	10.070 ns	9.240 ns	−0.830 ns	−8.2%
malformed	3.034 ns	2.791 ns	−0.243 ns	−8.0%
binary-unit	3.930 ns	3.727 ns	−0.203 ns	−5.2%
u64-max	17.050 ns	17.150 ns	+0.100 ns	+0.6%
plain	3.727 ns	4.011 ns	+0.284 ns	+7.6%
decimal-unit	3.930 ns	4.459 ns	+0.529 ns	+13.5%

IMO, the changes in plain and/or decimal-unit are probably measurement noise. It’s a rough comparison anyway, given the mbp’s big.little architecture and dynamic frequency scaling.

idk if the changes differ across different architectures, such as x86_64.

raw data

before:

Timer precision: 41 ns
parse                         fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ parse                                    │               │               │               │         │
   ├─ binary-unit             3.849 ns      │ 10.52 ns      │ 3.93 ns       │ 4.015 ns      │ 100     │ 102400
   ├─ decimal-unit            3.686 ns      │ 5.72 ns       │ 3.93 ns       │ 3.978 ns      │ 100     │ 102400
   ├─ fraction                5.069 ns      │ 6.575 ns      │ 5.111 ns      │ 5.186 ns      │ 100     │ 102400
   ├─ grouped                 9.911 ns      │ 15.73 ns      │ 10.07 ns      │ 10.27 ns      │ 100     │ 102400
   ├─ high-precision-binary   104.7 ns      │ 140.9 ns      │ 114.5 ns      │ 114.5 ns      │ 100     │ 102400
   ├─ high-precision-decimal  27.65 ns      │ 47.75 ns      │ 28.91 ns      │ 29.78 ns      │ 100     │ 102400
   ├─ malformed               2.75 ns       │ 3.97 ns       │ 3.034 ns      │ 3.033 ns      │ 100     │ 102400
   ├─ plain                   3.686 ns      │ 4.743 ns      │ 3.727 ns      │ 3.777 ns      │ 100     │ 102400
   ├─ small-fraction          6.696 ns      │ 7.551 ns      │ 6.779 ns      │ 6.842 ns      │ 100     │ 102400
   ╰─ u64-max                 16.95 ns      │ 17.92 ns      │ 17.05 ns      │ 17.08 ns      │ 100     │ 102400

after:

Timer precision: 41 ns
parse                         fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ parse                                    │               │               │               │         │
   ├─ binary-unit             3.726 ns      │ 11.33 ns      │ 3.727 ns      │ 3.809 ns      │ 100     │ 102400
   ├─ decimal-unit            4.418 ns      │ 5.192 ns      │ 4.459 ns      │ 4.502 ns      │ 100     │ 102400
   ├─ fraction                4.255 ns      │ 8.732 ns      │ 4.337 ns      │ 4.478 ns      │ 100     │ 102400
   ├─ grouped                 9.098 ns      │ 14.06 ns      │ 9.24 ns       │ 9.471 ns      │ 100     │ 102400
   ├─ high-precision-binary   54.46 ns      │ 71.92 ns      │ 58.51 ns      │ 58.24 ns      │ 100     │ 102400
   ├─ high-precision-decimal  16.09 ns      │ 23.94 ns      │ 16.91 ns      │ 17.64 ns      │ 100     │ 102400
   ├─ malformed               2.749 ns      │ 3.726 ns      │ 2.791 ns      │ 2.863 ns      │ 100     │ 102400
   ├─ plain                   3.93 ns       │ 8.528 ns      │ 4.011 ns      │ 4.207 ns      │ 100     │ 102400
   ├─ small-fraction          5.273 ns      │ 14.38 ns      │ 5.314 ns      │ 5.612 ns      │ 100     │ 102400
   ╰─ u64-max                 16.78 ns      │ 21.1 ns       │ 17.15 ns      │ 17.29 ns      │ 100     │ 102400

related

PR: #20

Issue: #2

[tisonkun]

Thanks for your contribution @Colerar!

I'll review this PR now or tomorrow. You can feel free to ping me the next time or I may miss a new opened PR.

[tisonkun]

I made one commit to fine tune the parse error.

But the whole parse error can be redesigned if anyone has a better idea.

[tisonkun]

Thanks! LGTM.