Feature request: compile-time hashes for `HeaderName::from_static`
还没有人认领这个 Issue。
- 主要语言
- Rust
- 星标
- 1.4k
- 派生
- 378
- 平均合并
- 1 天 21 小时
- 30 天内合并 PR
- 5
描述
Hi!
An almost complete rust newbie here (coming from C++, mostly), so please forgive my ignorance.
I believe it's a pretty common practice to have some company-wide standard headers for, say, tracing/authorization/etc., which are de-facto StandardHeaders in that sense.
However, since they aren't actually values of that enum, hashing them calls into FNV (i assume hashing a StandardHeader only hashes its discriminant, am i right?), and that FNV usage is measurable.
For example, i took the axum implementation from TechEmpower benchmarks, and did this: https://github.com/itrofimow/FrameworkBenchmarks/pull/7/files
Looking at flamegraphs, the contains_key amounts to ~3% of total CPU usage, most of it being spent in FNV, when replacing the CUSTOM_HEADERS with [ACCESS_CONTROL_ALLOW_CREDENTIALS, ACCESS_CONTROL_ALLOW_HEADERS, ACCESS_CONTROL_EXPOSE_HEADERS] (something of comparable length, basically) leads to the contains_key only taking ~0.3%.
Does it make sense to implement the optimization proposed, or do its drawbacks outweigh its performance benefits?
I have a clear understanding of how that could be done in C++ (we actually do so in the web-framework of ours, with its HeaderMap implementation being heavily inspired by what hyper offers), and would be glad to give it a try in Rust.
贡献指南
这个仓库没有索引到贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
从 HeaderName::from_static 和 issue 中描述的 contains_key 路径开始,然后比较 StandardHeader 与自定义 header 的哈希行为。使用链接的 TechEmpower 基准测试和 flamegraphs 测量当前开销;完成的标准是形成一种经过评审的编译期哈希方案,并提供基准测试证据及已达成一致的权衡方案。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- rust
- 领域
- backend-api-design, performance
- Issue 类型
- 功能
- 难度
- 5/5
- 预计耗时
- 一周以上
- 活跃度
- 停滞
- 描述清晰度
- 基本清楚
- 新手友好度
- 35/100