Browse Source
This has been a massive pain point for me personally due to the poor design of the Enum class leading to the common use cases used in the library being significantly slow. Since this Enum is not public facing in terms of *creation*, I can only implement the APIs that are used when *accessing* them. This Enum is a drop-in replacement to the pre-existing enum.Enum class except it comes with significant speed-ups. Since this is a lot to go over, I will let the numbers speak for themselves: In [4]: %timeit enums.try_enum(enums.Status, 'offline') 263 ns ± 34.3 ns per loop (7 runs, 1000000 loops each) In [5]: %timeit NeoStatus.try_value('offline') 134 ns ± 0.859 ns per loop (7 runs, 10000000 loops each) In [6]: %timeit enums.Status.offline 116 ns ± 0.378 ns per loop (7 runs, 10000000 loops each) In [7]: %timeit NeoStatus.offline 31.6 ns ± 0.327 ns per loop (7 runs, 10000000 loops each) In [8]: %timeit enums.Status.offline.value 382 ns ± 15.2 ns per loop (7 runs, 1000000 loops each) In [9]: %timeit NeoStatus.offline.value 65.5 ns ± 0.953 ns per loop (7 runs, 10000000 loops each) In [10]: %timeit str(enums.Status.offline) 630 ns ± 14.8 ns per loop (7 runs, 1000000 loops each) In [11]: %timeit str(NeoStatus.offline) 253 ns ± 3.53 ns per loop (7 runs, 1000000 loops each) In [12]: %timeit enums.Status('offline') 697 ns ± 8.42 ns per loop (7 runs, 1000000 loops each) In [13]: %timeit NeoStatus('offline') 182 ns ± 1.83 ns per loop (7 runs, 10000000 loops each)pull/2209/head
3 changed files with 92 additions and 59 deletions
Loading…
Reference in new issue