-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
improve import time by postponing optional imports #2379
Comments
For the record, I've noted the desispec import overhead when benchmarking fastspecfit (which has The other place where a large number of (potentially unnecessary) imports occur is in, e.g., E.g., if all I want is |
I would not object to deferring the import of |
Use with caution, but... While chasing a different issue, @segasai noticed https://peps.python.org/pep-0562/ that we can define module-level |
A wrapper script for easier human parsing from @dmargala : https://gist.github.com/dmargala/fcb1e9adf14f662155e138fe5f266226#file-importtrace-py e.g.
|
@dmargala identified that our occasional PMI init failures are related to large variations in the startup time of different MPI ranks before they connect to MPI. These were traced to variations in module-level import times, which further identified several surprisingly expensive steps. Some of these could be deferred into importing optional libraries only if needed by specific functions.
To explore further:
desispec.io.spectra -> desispec.spectra -> specutils dominates the import time, but is only needed for Spectra.to_specutils and Spectra.from_specutils. Part of the specutils expense is importing astropy.nddata which imports dask stuff, so the astropy.nddata imports would also have to be postponed.
desispec.pixgroup -> import healpy is expensive and appears to be unneeded.
desispec.tsnr -> astropy.convolution is expensive again because it touches astropy.nddata -> dask. This import could be deferred and/or replaced with scipy.signal.fftconvolve.
etc.
python -Ximporttime -c "import desispec.spectra"
gives a dizzying amount of info. @dmargala has visualization wrappers on that to simplify the output. Sharing that and/or a hackfest with him to refactor some of these imports could be useful.The text was updated successfully, but these errors were encountered: