aboutsummaryrefslogtreecommitdiffstats
path: root/testing/benches (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Generator: make `normalize_identifier` faster (#946)Libravatar René Kijewski2024-01-121-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.
* Clean up clippy warningsLibravatar Dirkjan Ochtman2020-01-021-6/+6
|
* Use 2018 edition idiomsLibravatar Dirkjan Ochtman2018-12-081-1/+0
|
* Move escaping benchmarks into askama_escape crateLibravatar Dirkjan Ochtman2018-11-141-66/+0
|
* Add bench for escapingLibravatar bott2018-11-051-1/+67
|
* Remove unused #[macro_use] attributeLibravatar Dirkjan Ochtman2018-11-041-1/+0
|
* Fix formatting with cargo fmtLibravatar Dirkjan Ochtman2018-07-021-4/+16
|
* Add benchmarks to the Askama repoLibravatar Dirkjan Ochtman2018-06-281-0/+59