... plus some clean-up.
It was only after I came up with the scheme using
`const fn from_bytes(&[u8]) -> Option<StandardHeader>`
that I noticed the debug+wasm32-wasi version of `parse_hdr`, which had
something very similar.
While cleaning up that function, I realized it still would still panic
if an attempted name was too long, which had been fixed for all other
targets and profiles in #433. Then, I thought it would be worth seeing
if the use of `eq!` in the primary version of `parse_hdr` still made any
difference.
And, it would not appear so. At least not on x86_64, nor wasm32-wasi run
via wasmtime. I've run the benchmarks a number of times now, and it
seems the only significant performance change anywhere is actually that
of `HeaderName::from_static` itself, which now seems to run in about 2/3
the time on average.
Unfortunately, `const fn` still cannot `panic!`, but I've followed the
lead from `HeaderValue::from_static`. While that version required 1.46,
this new function requires 1.49. That is almost 8 months old, so
hopefully this isn't too controversial!
These constructors don't expose the internal `Bytes` type, but instead
will try to downcast the argument to prevent a copy. If the types don't
match up (a user provides an older version of `Bytes`), the value will
just be copied.
Adds:
- `HeaderValue::from_maybe_shared`
- `HeaderValue::from_maybe_shared_unchecked`
- `Uri::from_maybe_shared`
- `Authority::from_maybe_shared`
- `PathAndQuery::from_maybe_shared`
* 2018 edition, babey!
* run `cargo fix --edition-idioms`
* yes, we do intend to drop the iterator, thanks rustc!
* cargo fmt
* aggressive min rustc version bump to fix travis
* 1.37 is not out, oops
The previous implementation of `FastHasher`, while fast, resulted in a
high number of collisions. The fast hash function has been switched to
FNV. After making the switch, benchmarks showed that using static hash
values for standard HTTP headers is actually slower than hashing them on
demand with FNV. This is because hashing standard headers only requires
hashing the enum discriminant. Also, benchmarks show that using a
sequential scan map for small header maps isn't really worth it either.
Sean McArthur