aboutsummaryrefslogtreecommitdiffstats
path: root/testing/benches (unfollow)
Commit message (Collapse)AuthorFilesLines
2024-01-12Generator: make `normalize_identifier` faster (#946)Libravatar René Kijewski1-0/+694
`normalize_identifier` is called quite often in the generator, once for every variable name or path element that is written. This PR aims to speed up the function by * using a per-length input string length replacement map * binary searching the replacement map instead of a linear search Diffent, but functionally equivalent implementations were compared: ```text * linear search in one big map: 348.44 µs * binary search in one big map: 334.46 µs * linear search in a per-length map: 178.84 µs * binary search in a per-length map: 154.54 µs * perfect hashing: 170.87 µs ``` The winner of this competition is "binary search in a per-length map". It does not introduce new dependencies, but has the slight disadvantage that it uses one instance of `unsafe` code. I deem this disadvantage acceptable, though. Nb. It was also tested if a variant that only stores the replaced string would be faster. This "optimization" proved to be slower for all implementations except "binary search in a per-length map", for which it has the same runtime. Without a clear advantage to use the "optimized version", I chose to use the more easy to read slice of tuples variant. Obviously, for all measurements: YMMV.
2020-01-02Clean up clippy warningsLibravatar Dirkjan Ochtman1-6/+6
2018-12-08Use 2018 edition idiomsLibravatar Dirkjan Ochtman1-1/+0
2018-11-14Move escaping benchmarks into askama_escape crateLibravatar Dirkjan Ochtman1-66/+0
2018-11-05Add bench for escapingLibravatar bott1-1/+67
2018-11-04Remove unused #[macro_use] attributeLibravatar Dirkjan Ochtman1-1/+0
2018-07-02Fix formatting with cargo fmtLibravatar Dirkjan Ochtman1-4/+16
2018-06-28Add benchmarks to the Askama repoLibravatar Dirkjan Ochtman1-0/+59