Jannik Kissinger

Thanks for reporting this. It might be due to an issue with the library h3, which is a dependency introduced in v6.0.0 Could you double check and report if not...

Yes, exactly. If the time increases even further considerably then it is likely that Numba is not the cause of the delay you are reporting.

Yes, that's possible. It seems like Numba is actually not working properly meaning that using pure python code is as fast as the Numba equivalents. I wonder if there is...

From the results you posted I am pretty sure it is a Numba issue (since installing Numba does not seem to change the timing). It is however strange when the...

Ok, Stange. That is a long time for just a variable evaluation. Can you time a second evaluation as well please?

Ok. That makes more sense. Can you please double check that the general Numba benchmarks work for the exact same Numba version you are using with timezonefinder?

And please also double check you are benchmarking the `njit` functionality of Numba since that is what `timezonefinder` is using: https://github.com/jannikmi/timezonefinder/blob/master/timezonefinder/utils.py

`@numba.jit(nopython=True,...)` used in the benchmarks should be equivalent to `@numba.njit` I have the gut feeling that this has something todo with the initial time required by Numba to just in...

An alternative perhaps preferable way of ensuring the same thing is being measured is deleting the cache every time you run the benchmark (also locally)

I am not an expert on this, but at least the caching behavior could be different in the Docker image. Perhaps it is so slow overall because caching is not...