Feature request: compile-time hashes for `HeaderName::from_static`
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- rust
- Lĩnh vực
- backend-api-design, performance
Hướng nghiên cứu
Bắt đầu với HeaderName::from_static và đường dẫn contains_key được mô tả trong issue, sau đó so sánh hành vi hashing của StandardHeader và các header tùy chỉnh. Sử dụng benchmark TechEmpower được liên kết và các flamegraph để đo chi phí hiện tại; được xem là hoàn thành khi có một phương pháp hashing tại thời điểm biên dịch đã được review, kèm bằng chứng benchmark và các đánh đổi đã được thống nhất.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Rust
- Star
- 1.4k
- Fork
- 378
- Merge trung bình
- 1 ngày 21 giờ
- Pull request đã merge (30 ngày)
- 5
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của hyperium/http
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 62/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 58/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 62/100
Tất cả issue của hyperium/http
Issue tương tự
-
Browser (wasm) relay client cannot connect to relays whose URL has a trailing-dot FQDN hostname Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
n0-computer/iroh#4550 ·
-
impl detach for native Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
paritytech/zombienet-sdk#591 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
farion1231/cc-switch#7638 · 1 bình luận ·
-
onnx-ir re-exports ModelProto and GraphProto but not NodeProto, AttributeProto and AttributeType Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100