5 Commits

Author SHA1 Message Date
René Kijewski
75dd2c92f3 Update dependencies
* Update version-incompatible dependencies in examples.
* Update version-incompatible dev-dependencies.
* Replaced deprecated `criterion::black_box`.
* Add `features = "simd"` to `winnow`. This adds a transitive
  dependency to `memchr`, on which we already depend on directly.
2025-05-18 23:06:41 +02:00
Guillaume Gomez
3b52c907c3 Rename rinja into askama 2025-03-11 19:31:06 +01:00
René Kijewski
4b44189809 ci: update formatting for edition=2024 2024-09-24 02:07:17 +02:00
Guillaume Gomez
2d80cc3524 Rename everything to rinja 2024-06-17 15:58:52 +02:00
René Kijewski
3cddb91889
Generator: make normalize_identifier faster (#946)
`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.
2024-01-12 20:41:46 +01:00