net: Don't use checked arithmetic when parsing numbers with known max digits

[okaneco]

Add a branch to Parser::read_number that determines whether checked or regular arithmetic is used.

• If max_digits.is_some(), then we know we are parsing a u8 or u16 because read_number is only called with Some(3) or Some(4). Both types fit within a u32 without risk of overflow. Thus, we can use plain arithmetic to avoid extra instructions from checked_mul and checked_add.

Add benches for IpAddr, Ipv4Addr, Ipv6Addr, SocketAddr, SocketAddrV4, and SocketAddrV6 parsing

[rustbot]

r? @cuviper

rustbot has assigned @cuviper.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[okaneco]

I wasn't sure whether to add the functionality to the current parsing function or create a new function. I chose this way to reduce call-site churn.

For the benchmarks, I took the values from the tests folder. If there are better suggestions, I have no problem using those instead.

I saw a ~20% improvement on benchmarks on my laptop.

Before

benchmarks:
    net::addr_parser::bench_parse_ipaddr_v4           62.00ns/iter  +/- 2.00ns
    net::addr_parser::bench_parse_ipaddr_v6_compress 211.00ns/iter  +/- 9.00ns
    net::addr_parser::bench_parse_ipaddr_v6_full     290.00ns/iter  +/- 6.00ns
    net::addr_parser::bench_parse_ipaddr_v6_v4       194.00ns/iter  +/- 6.00ns
    net::addr_parser::bench_parse_ipv4                61.00ns/iter  +/- 3.00ns
    net::addr_parser::bench_parse_ipv6_compress      193.00ns/iter +/- 29.00ns
    net::addr_parser::bench_parse_ipv6_full          284.00ns/iter +/- 15.00ns
    net::addr_parser::bench_parse_ipv6_v4            183.00ns/iter  +/- 6.00ns
    net::addr_parser::bench_parse_socket_v4           85.00ns/iter  +/- 2.00ns
    net::addr_parser::bench_parse_socket_v6          235.00ns/iter +/- 13.00ns
    net::addr_parser::bench_parse_socket_v6_scope_id 248.00ns/iter +/- 31.00ns
    net::addr_parser::bench_parse_socketaddr_v4       87.00ns/iter  +/- 4.00ns
    net::addr_parser::bench_parse_socketaddr_v6      254.00ns/iter +/- 10.00ns

After

benchmarks:
    net::addr_parser::bench_parse_ipaddr_v4           48.00ns/iter  +/- 1.00ns
    net::addr_parser::bench_parse_ipaddr_v6_compress 170.00ns/iter  +/- 4.00ns
    net::addr_parser::bench_parse_ipaddr_v6_full     227.00ns/iter  +/- 4.00ns
    net::addr_parser::bench_parse_ipaddr_v6_v4       158.00ns/iter  +/- 3.00ns
    net::addr_parser::bench_parse_ipv4                45.00ns/iter  +/- 2.00ns
    net::addr_parser::bench_parse_ipv6_compress      160.00ns/iter +/- 12.00ns
    net::addr_parser::bench_parse_ipv6_full          225.00ns/iter  +/- 7.00ns
    net::addr_parser::bench_parse_ipv6_v4            146.00ns/iter  +/- 3.00ns
    net::addr_parser::bench_parse_socket_v4           69.00ns/iter  +/- 6.00ns
    net::addr_parser::bench_parse_socket_v6          210.00ns/iter +/- 11.00ns
    net::addr_parser::bench_parse_socket_v6_scope_id 218.00ns/iter +/- 24.00ns
    net::addr_parser::bench_parse_socketaddr_v4       71.00ns/iter  +/- 3.00ns
    net::addr_parser::bench_parse_socketaddr_v6      216.00ns/iter  +/- 5.00ns

[cuviper]

It must be strictly less, because you can overflow u32 with the same number of digits as u32::MAX.

Maybe we should also add a debug_assert! for this? Just for future proofing to be checked in CI, without affecting release builds.

[okaneco]

Changed the invariant comment and added a debug_assert! checking that max_digits is below 10.

I could have used max_digits <= u32::MAX.ilog10() but that seems less clear for future readers as that rounds down to 9.

[cuviper]

Thanks!

@bors r+

[bors]

📌 Commit 69637c9 has been approved by cuviper

It is now in the queue for this repository.

[jhpratt]

@bors rollup=never

(due to perf implications)

[bors]

⌛ Testing commit 69637c9 with merge 96561a8...

[bors]

☀️ Test successful - checks-actions
Approved by: cuviper
Pushing 96561a8 to master...

[rust-timer]

Finished benchmarking commit (96561a8): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.9%	[-2.9%, -2.9%]	1
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 644.654s -> 644.518s (-0.02%)
Artifact size: 175.03 MiB -> 175.01 MiB (-0.01%)