IpAddr::from_str is unnecessarily slow for IPv6 addresses

[jyn514]

from_str is implemented like so:

rust/library/std/src/net/parser.rs

Lines 226 to 229 in 5f4e067

	/// Read an IP Address, either IPv4 or IPv6.
	fn read_ip_addr(&mut self) -> Option<IpAddr> {
	self.read_ipv4_addr().map(IpAddr::V4).or_else(move || self.read_ipv6_addr().map(IpAddr::V6))
	}

This unnecessarily penalizes ipv6 addresses, because the parser will always do a full linear scan of the input before it even starts to parse the address. Instead, it could use the knowledge that IPv4 addresses are at most 15 bytes long to skip directly to read_ipv6_addr for longer strings.

@rustbot label: +I-slow +T-libs +C-enhancement

[jyn514]

IPv4 addresses are at most 15 bytes long

This is true because octal addresses were banned in #83652.

[equt]

@rustbot claim

[equt]

I do agree that it could benefit the read_ip_addr, and maybe also the read_socket_addr. But I believe that

the parser will always do a full linear scan of the input

is not true.

If I didn't get it wrong, the current parser will realize the input is an IPv6 after parsing at most four bytes. And if we're going to use the input size as a factor to guess, something like 0000::1 will still suffer from the parser's backtracking.

[mbartlett21]

the current parser will realize the input is an IPv6 after parsing at most four bytes

That seems correct

rust/library/std/src/net/parser.rs

Lines 145 to 148 in 21b0325

	let mut groups = [0; 4];
	for (i, slot) in groups.iter_mut().enumerate() {
	*slot = p.read_separator('.', i, |p| {

[Noratrieb]

There are probably still further performance improvements that could be made, but unless someone has a real-world use case for parsing that many IPv6 addresses, this seems unnecessary.

[saethlin]

unless someone has a real-world use case for parsing that many IPv6 addresses

My employer maintains an ETL process that mostly chomps through netflow data, spending a nontrivial amount of cycles parsing IP addresses depending on configuration.

I don't particularly see any reason to close this; if we can have super-fast IP address parsing, we should.