You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is likely related to how guvectorize works. It has two modes and we're using "eager, decoration-time compilation". In other words, we're compiling functions during import.
Eager, or decoration-time, compilation: If you pass one or more type signatures to the decorator, you will be building a NumPy universal function (ufunc). The rest of this subsection describes building ufuncs using decoration-time compilation.
Lazy, or call-time, compilation: When not given any signatures, the decorator will give you a Numba dynamic universal function (DUFunc) that dynamically compiles a new kernel when called with a previously unsupported input type. A later subsection, “Dynamic universal functions”, describes this mode in more depth.
Potential solutions?
Use lazy, call-time compilation
Use lazy imports of numba modules
Use caching
The text was updated successfully, but these errors were encountered:
After some investigation there also seem to be an issue when using np.linalg.norm inside of numba gufuncs. Substituting it with a custom jitted function improves import time considerably (not sure about performance impact).
Importing the library seems to be significantly slowed down by numba, see output of
This is likely related to how
guvectorize
works. It has two modes and we're using "eager, decoration-time compilation". In other words, we're compiling functions during import.Potential solutions?
The text was updated successfully, but these errors were encountered: