-
Notifications
You must be signed in to change notification settings - Fork 277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: compile-time hashes for HeaderName::from_static
#653
Comments
Hey there! It could make sense, I think it would depend on what the implementation looks like. Would you be willing to discuss it here first? That could help save time before code is written :) |
Thank you for the, dare i say, blazingly fast response :) Sure. In my mind it could be implemented either via adding an In both cases something like https://crates.io/crates/const-fnv1a-hash would be needed, too. |
It's a fine thing to explore, but we'll want to weigh how much adding that affects performance of other parts. If it's much slower in other paths, we might not end up accepting the change. I imagine we don't really need another dependency, the FNV algorithm is tiny and having the |
I've got a draft for this, which right now apparently breaks dependent crates because of
Not really sure what this is about, but i guess there should be a workaround. Benchmarks show a slowdown for These results confuse me, and i would assume I've done something completely nonsensical if not for the tests passing; could you @seanmonstar please have a glance on this? - I don't request a review yet, more of a sanity check, and whether this direction has potential. |
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
StandardHeader
s 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 theCUSTOM_HEADERS
with[ACCESS_CONTROL_ALLOW_CREDENTIALS, ACCESS_CONTROL_ALLOW_HEADERS, ACCESS_CONTROL_EXPOSE_HEADERS]
(something of comparable length, basically) leads to thecontains_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.
The text was updated successfully, but these errors were encountered: