This cuts varcon lookup times in half but I still suspect slower than
phf. Like with bsearch and unlike, the cost is consistent between hits
and misses.
At least this doesn't have the compile hit of PHF + unicase. Maybe I
should experiment with integrating a non-const-fn variant of unicase
with PHF and give up on all of this extra complexity.
Before, only some dicts did we guarentee were pre-sorted. Now, all are
for-sure pre-sorted.
This also gives each dict the size-check to avoid lookup.
But this is really about refactoring in prep for playing with other
lookup options, like tries.
This is mostly to give implementation flexibility for changing out how
we store the data to reduce compilation memory usage.
This does have performance impact, jumping from ~220ns to ~320ns for a
dict lookup, according to our micro benchmarks.
Variant support slows us down by 10-50$. I assume most people will run
with `en` and so most of this overhead is to waste. So instead of
merging vars with dict, let's instead get a quick win by just skipping
vars when we don't need to. If the assumptions behind this change over
time or if there is need for speeding up a specific locale, we can
re-address this.
Before:
```
check_file/Typos/code time: [35.860 us 36.021 us 36.187 us]
thrpt: [8.0117 MiB/s 8.0486 MiB/s 8.0846 MiB/s]
check_file/Typos/corpus time: [26.966 ms 27.215 ms 27.521 ms]
thrpt: [21.127 MiB/s 21.365 MiB/s 21.562 MiB/s]
```
After:
```
check_file/Typos/code time: [33.837 us 33.928 us 34.031 us]
thrpt: [8.5191 MiB/s 8.5452 MiB/s 8.5680 MiB/s]
check_file/Typos/corpus time: [17.521 ms 17.620 ms 17.730 ms]
thrpt: [32.794 MiB/s 32.999 MiB/s 33.184 MiB/s]
```
This puts us inline with `--no-default-features --features dict`
Fixes#253
These were found while running `typos` on Linux and inspecting a
sampling of the results. #249 represents additional changes to make.
There were some identifiers, that looked like hardware registers, that
I'm unsure of what can be done for them.
Bypass hashing when we know (through str::len) that a word won't be in
the dict.
Master:
```
real 0m26.675s
user 0m33.683s
sys 0m4.535s
```
With this change
```
real 0m24.432s
user 0m32.492s
sys 0m4.190s
```
Bypass hashing when we know (through str::len) that a word won't be in
the dict.
Master:
```
real 0m26.675s
user 0m33.683s
sys 0m4.535s
```
With this change:
```
real 0m24.060s
user 0m31.559s
sys 0m4.258s
```
`HashMap::get` (at least hashbrown) hashes before getting and doesn't
check if dict is empty. For the custom dict, a common use case will
have the dict be empty.
Master:
```
real 0m26.675s
user 0m33.683s
sys 0m4.535s
```
Bypassing `HashMap::get`
```
real 0m16.415s
user 0m14.519s
sys 0m4.118s
```
On a moderately sized repo.
If we have to hash for the custom dict, we might as well be fast about
it. We do not need a cryptographically secure algorithm since the
content is fixed for the user.
Master:
```
real 0m26.675s
user 0m33.683s
sys 0m4.535s
```
With ahash:
```
real 0m23.993s
user 0m30.800s
sys 0m4.440s
```
Sometimes you just have to live with a typo or its done intentionally
(like weird company names). With this commit, a user can now identifier
blessed identifiers and words.
This is ostly what is needed for #9 but sometimes people will have
common typos that they'll want to provide corrections for.
The goal is to be as accepting and unobtrusive to new code bases as
possible. To this end, we correct typos into the closest english
dialect.
If someone wants to opt-in, they can have typos correct to a specific
english dialect.
Fixes#52Fixes#22
Some of the other spell checkers already do this. While I've not checked
where we might need it for our dictionary, this will be important for
dialects.
