Allow datrie with recent Python / Drop datrie?

[gsnedders]

We limit the datrie optional dependency to Python < 3.7, because prior to the 0.8 release it didn't support Python 3.7. Probably, we should either:

• Require datrie >= 0.8
• Drop support for datrie (this depends in part of the perf impact of doing so)

[hugovk]

Please see PR #446 to require datrie 0.8+ to support Python 3.7.

But datrie doesn't yet support Python 3.8: pytries/datrie#73.

[gsnedders]

But it doesn't yet support Python 3.8: pytries/datrie#73

Ergh, yeah, okay, should just take a look at the perf impact of just dropping support.

[gsnedders]

Ergh, yeah, okay, should just take a look at the perf impact of just dropping support.

In a bunch of more ordinary cases the perf impact seems to be approximately nothing. I suggest we just drop support for datrie? I doubt even in the worst case it's going to be significant?

[hugovk]

If keeping it only offers minimal or zero performance benefit, sounds like a good idea to drop, it'll reduce the maintenance burden, as it seems this will happen for every new (now annual) Python release. And we're 4 months since 3.8 came out, and Datrie support is still pending.

[tacaswell]

datries 0.8.2 should support py37 and py38.

[gsnedders]

On the two tests I have that are pretty heavy on entities, we get:

Mean +- std dev: [datrie_without] 293 ms +- 6 ms -> [datrie_with] 291 ms +- 6 ms: 1.01x faster (-1%)
Mean +- std dev: [datrie_without] 104 ms +- 1 ms -> [datrie_with] 104 ms +- 1 ms: 1.01x faster (-1%)

On the whole, despite both tests showing statistically significant perf gains, I think they're small enough they're not worth it?

It's probably worthwhile noting the pure-Python entity lookup with was much slower when datrie was added as an optional dependency, and as such the perf gain from it was much larger.

[gsnedders]

#455 dropped datrie.