Feature request: compile-time hashes for `HeaderName::from_static`
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 35/100
- Type d'issue
- Fonctionnalité
- Clarté
- Plutôt claire
- Activité
- À l'abandon
- Stack technique
- rust
- Domaine
- backend-api-design, performance
Piste de recherche
Commencez par HeaderName::from_static et le chemin contains_key décrit dans l’issue, puis comparez le comportement du hashing de StandardHeader et des en-têtes personnalisés. Utilisez le benchmark TechEmpower lié et les flamegraphs pour mesurer le coût actuel ; le travail est considéré comme terminé lorsqu’une approche de hashing à la compilation a été revue, avec des éléments probants issus des benchmarks et des compromis convenus.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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.
- Langage dominant
- Rust
- Étoiles
- 1.4k
- Forks
- 385
- Merge moyen
- 2 j 4 h
- PR mergées (30 j)
- 1
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de hyperium/http
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
-
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
-
Difficulté 3/5 1-2 jours Accessibilité débutants 62/100
-
Difficulté 3/5 1-2 jours Accessibilité débutants 58/100
-
Difficulté 3/5 1-2 jours Accessibilité débutants 62/100
Toutes les issues de hyperium/http
Issues similaires
-
Docs: refresh target-app-parity and file-format-parity against mainPeut-être pris @vangel76 l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
storytold/photocraft#4417 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
bevyengine/dlss_wgpu#37 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
Les mainteneurs répondent en général sous 1 jour
-
wgpu error: Validation ErrorOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 63/100
bherbruck/solvecraft#369 ·
-
enhancement
Difficulté 1/5 Moins d'une heure Accessibilité débutants 83/100
alunduil/git-worktree-poi#11 ·