hyperium / hyperium/http

Optimize try_reserve by implementing TODO (remove redundant overflow check)

Open
#801 1 comment 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

Following up on #787, I noticed the TODO comment suggests removing
the checked_add since it's redundant given MAX_SIZE bounds.

Since I'm familiar with this code area,
I wanted to implement this small optimization. Let me know if now is
a good time or if you'd prefer to defer this.

Link(Fix): https://github.com/AriajSarkar/http/blob/c567928c430262295b3a587ecc3aa00f657f4704/src/header/map.rs#L746

Problem

Current implementation (line 746-752):

// TODO: This can't overflow if done properly... since the max # of
// elements is u16::MAX.
let cap = self
    .entries
    .len()
    .checked_add(additional)
    .ok_or_else(MaxSizeReached::new)?;

The checked_add is redundant because:

  1. self.entries.len() <= MAX_SIZE (data structure invariant)
  2. MAX_SIZE = 32,768 (fits in u16)
  3. Even with additional + self.entries.len(), we validate against MAX_SIZE later via to_raw_capacity

Solution

Replace checked_add with an early bounds check:

// Early bounds check: Since self.entries.len() <= MAX_SIZE (invariant),
// and MAX_SIZE fits in u16, we can avoid checked_add by validating
// that additional won't cause the total to exceed MAX_SIZE.
let current_len = self.entries.len();
if additional > MAX_SIZE.saturating_sub(current_len) {
    return Err(MaxSizeReached::new());
}

// Safe: We've verified that current_len + additional <= MAX_SIZE,
// which is well within usize range, so no overflow is possible.
let cap = current_len + additional;

Benefits

  1. Performance: Eliminates one checked_add operation per try_reserve call
  2. Clarity: Makes the MAX_SIZE constraint explicit upfront
  3. Early failure: Rejects invalid requests before unnecessary computation

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

Start in src/header/map.rs around try_reserve and the TODO at line 746, then review the MAX_SIZE and to_raw_capacity assumptions described in the issue and linked discussion #787. Done means the redundant overflow check is removed without changing capacity-limit behavior; run the repository's existing tests to verify the change.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design
Issue type
Refactor
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.