Skip to content

proto/h1: spurious copy-allocation in request parsing hotpath #3574

New issue
New issue
Closed
#3575
Closed
proto/h1: spurious copy-allocation in request parsing hotpath#3574
#3575
Labels
A-http1Area: HTTP/1 specific.C-performanceCategory: performance. This is making existing behavior go faster.E-easyEffort: easy. A task that would be a great starting point for a new contributor.
@lucab

Description

@lucab
lucab
opened on Feb 19, 2024

Version
hyper-1.1.0

Platform
Linux x86_64

Description

I was looking at the memory allocation patterns of a hyper-1.0 HTTP1 server with a fastwebsocket endpoint (basically equivalent to this example) and I noticed that there is a spurious memory copy-allocation in the uri.parse()? URI parsing logic here:

hyper/src/proto/h1/role.rs

Lines 157 to 168 in 00a703a

match req.parse_with_uninit_headers(bytes, &mut headers) {
Ok(httparse::Status::Complete(parsed_len)) => {
trace!("Request.parse Complete({})", parsed_len);
len = parsed_len;
let uri = req.path.unwrap();
if uri.len() > MAX_URI_LEN {
return Err(Parse::UriTooLong);
}
subject = RequestLine(
Method::from_bytes(req.method.unwrap().as_bytes())?,
uri.parse()?,
);

This is visible in memory profiles as a Bytes::copy_from_slice() coming from a Uri::from_str():

uri-parse

I suspect this is the root-cause of some performance impact that has been noticed in the CPU profiles at #3258 (comment).

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-http1Area: HTTP/1 specific.C-performanceCategory: performance. This is making existing behavior go faster.E-easyEffort: easy. A task that would be a great starting point for a new contributor.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions