hyperium / hyperium/http

Document byte-by-byte comparisons (eq! macro) in name.rs

Open
#429 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
1.4k
Forks
378
Avg merge
1d 21h
Merged PRs (30d)
5

Description

I was recently reading name.rs, and was surprised to see a lot of hand-coded byte-by-byte comparisons for reading header names:
https://github.com/hyperium/http/blob/975dbdd70a882fbf74a77a5b90ad190602bb98ac/src/header/name.rs#L1312-L1320

I'm curious why the code is written this way, rather than, say, with a match operator that would allow the compiler to optimize the comparisons appropriately. I see that @alexcrichton had a similar question during initial review of this code:

https://github.com/hyperium/http/pull/13/files#diff-45d89276e2be4715b26dc4e575f4153eR251

@carllerche I realize you wrote this code over 3 years ago, but would you be willing to take a second look and document the logic here? I'm assuming it's for performance but it would be good to know what specific performance problems were being worked around, and whether they've been improved in subsequent compiler releases.

Thanks,
Jacob

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read src/header/name.rs around lines 1312-1320 and the linked historical pull request discussion. Document why the eq! macro uses byte-by-byte comparisons, including any performance rationale that can be established from the existing code or discussion. Done means the logic and motivation are explained near the implementation.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
networking
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.