avoid cloning the uri/path

[yanns]

extract of #2865

[mladedav]

Looks good.

[jplatte]

I wonder whether we should run any benchmarking on this. In theory this could regress things as the request parts are moved around more (into_parts, from_parts).

[yanns]

I wonder whether we should run any benchmarking on this. In theory this could regress things as the request parts are moved around more (into_parts, from_parts).

I don't think this could regress things.

let (mut parts, body) = req.into_parts(); is just a destructure of the Request:

    #[inline]
    pub fn into_parts(self) -> (Parts, T) {
        (self.head, self.body)
    }

and Request::from_parts(parts, body) is in the other direction:

    #[inline]
    pub fn from_parts(parts: Parts, body: T) -> Request<T> {
        Request { head: parts, body }
    }

Both should be no-op.

[jplatte]

Both will involve moving things around on the stack, which is not a no-op. In many cases such moves are optimized out when compiling with optimizations, but it's not guaranteed.

[yanns]

I don't have the expertise for this.
I was assuming that destructuring a tuple for example would be no-op.
And I'm assuming that avoiding duplicating the uri path is worth it to avoid allocations.

[jplatte]

Okay, I'll look into it a bit later, if time permits. I think we have some existing benchmarks that I can run, probably need to add some more to distinguish short / long paths.

[jplatte]

Ran benchmarks locally, the most pronounced result was an improvement for the only test that has a >8 byte long path.

Mixed results for other benchmarks, likely just noise.