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
```
This reverts commit 0052617fcd.
The fix for #134 was backwards. It turns out `overrides` is for
including rather than ignoring. Will need to look at this further.
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.
THis is to help with cases like a monorepo with vendored dependencies.
A user might want to search (`.ignore`) them but not hold the code to
the same standards as first-party code.
Fixes#134
