optimize ipv4 address parsing

[shikharish]

Goal: significant performance improvement while parsing ipv4 addresses.

[the-moisrex]

Since I've already wasted way too much time on optimizing this prematurely (most-likely) about 2 years ago, here's some benchmarks for difference versions of inet_pton4 and ipv6 and a bunch more.

https://github.com/the-moisrex/webpp/tree/dev/benchmarks/ip

But I believe IPv4 hosts in Ada have acceptable performances. Any specific reason why you'd want more?

[shikharish]

Have a look at this.
It might help implementing this.

[the-moisrex]

5ns improvement is good when it adds up.

But parsing IPv4 in URLs is different from just doing inet_pton4; for example see my implementation of parsing host ipv4 vs normal ip addresses.

Host ipv4 supports hex and octal and whole lot of stupid stuff that it shouldn't have in the first place. There are literally infinite ways we can write every single ipv4 address.

[shikharish]

Of course, we are being optimistic here. Let me try to implement and see the results.

[shikharish]

@lemire
I have a doubt. As @the-moisrex mentioned, the parser does a lot of things to support the standard. In practice though, "well-formed" ipv4 addresses(a.b.c.d) are overwhelmingly more common than others(hex,octal, short forms, etc.) in real inputs(for example, network traces).

If we add a hot-path for the well-formed ip addresses, we can(very probably will) gain some performance impact (a rough implementation ran on a simple benchmark improved parse time from 182ns/ip -> 150ns/ip for an all well-formed ip dataset but also regressed 184ns/ip -> 189ns/ip for an all hex+octal ip dataset).

What do you think? I am just unsure if results similar to this are acceptable and worthwile to pursue.

[shikharish]

We can also optimize the hex and octal parsers but that is another issue.

[the-moisrex]

There is another places where we can optimize with the same idea @shikharish is suggesting. From the top of my head, during parsing the authority, we first have to check if the authority contains a username and password, or is it the host.

So we're essentially iterating the host at least twice; what we can do we can assume it's a host, until we find an '@' and then go back and re-parse it. User infos in URLs are deprecated but we still have to support them, but we at least can put the pressure of parsing on unhappy paths like the above suggestion.

So, yeah, removing things from the happy path to the unhappy path is a repeating theme in this library.

Though the gain here is too little IMHO.

[lemire]

The relevant code section is here:

ada/src/url.cpp

Line 466 in dfefbea

if (checkers::is_ipv4(host.value())) {

We currently do not have an URL/ipv4 benchmark per se.

The first step would be to build a good benchmark.

We do care if we speed things up by 5% or more in a common case as these gains tend to add up.