Speed up first import

[alecandido]

Compilation is needed only once per installation, nevertheless it is a bit annoying that actually the first time you try to run you don't have any feedback for a while.

There is an easy way to speed up compilation, since at the moment we are doing it on a single core. We can just add to the decorators:
https://github.com/N3PDF/eko/blob/47ad7d011bd853a86fe2cf7239931e28addb958b/src/eko/kernels/evolution_integrals.py#L18
the simple kwarg parallel=True.

https://numba.pydata.org/numba-doc/latest/user/threading-layer.html

If a code base does not use the threading or multiprocessing modules (or any other sort of parallelism) the defaults for the threading layer that ship with Numba will work well, no further action is required!

[scarrazza]

Sorry @alecandido, I was talking to Felix and what you say is completely wrong XD.
Parallel true, allows you to use numba.prange and he automatic parallelization through omp, tbb, etc.
This has nothing to do with AOT or JIT compilation.

[alecandido]

Got it.

After investigation, looks like there is no way in numba to control compilation options (and yes, it seems to compile on a single core).
Most likely the multithreaded compilation is still lacking in llvm: https://reviews.llvm.org/D52193 (it looks like a lot of compilers are still single threaded, e.g. even rustc is based on llvm, so most likely the parallelization is at the level of build tool).

To improve, there are still multiple ways available:

1. post install scripts (to compile code at install time)
2. distribute cache built in a workflow
3. hope for numba doing something

Comments on the three:

1. poetry does not support this (see this Support for custom commands and functions python-poetry/poetry#265), and it is fine, fewer things to debug (that might even be more annoying to)
2. this would make eko architecture dependent, and we should distribute multiple package with built extensions
3. actually, I didn't find anywhere (neither in cache introduction, nor in related notes) that the function should be cached on import, and it would be meaningful to cache it on first run since it is still jit and not AOT; if it would really behave like this it'd be much more intuitive: non-blocking until an actual computation is expected

If we agree on 3., then I'd close this one, we can look more carefully if we're introducing somehow this behavior, and otherwise consider to ask for help on numba repository.

[felixhekhorn]

Closing in favor of #94