Reduce import time

[saimn]

Ref #4598

• Avoid to import utils.console in the logger setup. The import will be done when the first logging message is printed.
• I also moved the units import in utils.console to a local one. With the previous change it is useless, but I think it may still be useful on some cases or for command-line scripts (when Spinner or ProgressBar are used).

With these changes, the import time goes down from ~480ms to ~250ms on my laptop. The remaining time is mostly in developer specific stuff (subprocess call to get the git hash for the version string), so the import time will be even better for released package.

[eteq]

Yep, I confirm the roughly ~2x improvement in import time. Nice find, @saimn!

Two suggestions:

• Can you add a comment above both of the imports to indicate that they are there specifically as a performance measure? That will prevent someone from moving them back given that the usual import style we prefer is most-stuff-at-the-top.
• Add a changelog entry, probably under "Other Changes" indicating that the import astropy time has been improved by a factor of 2x.

There's a bit of a question what version this goes in. I tend toward 1.2 because it's not specifically a bug/docs fix. But I'm open to other opinions.

[pllim]

I was going to ask @MSeifert04 to give this a try when the tests pass but the tests are taking forever.

[MSeifert04]

It's almost 3x faster doing import astropy with these changes (but no improvement when doing e.g. from astropy.nddata import NDData but there units are imported so I guess that's ok).

[saimn]

@eteq - Done, 1.2 seems fine.

@MSeifert04 - Yes, it will have only a minor effect for subpackages. For nddata, a quick look seems to show that half of the import time comes from the import of coordinates, which is used only in Cutout2D.

[eteq]

Alright, merged, thanks @saimn.

@MSeifert04 @saimn - yes, a lot of the long import effects come from the underlying situation that importing everything is always slower than importing some things.

I think that there's a balance to be considered here - there's often a clarity/performance tradeoff when it comes to imports: it may be clearer to put them all at the top at the cost of a bit of performance. This particular one is no-brainer because import astropy is fairly generic, but I'm not so sure we would want to move e.g. the nddata imports, as a lot of use cases for nddata might involve importing coordinates anyway. So in case you're tempted to go hunting for these kinds of optimizations, consider that they we may not want to always do them. Fair warning ;)

[saimn]

@eteq - I agree, this kind of optimization should be reserved for specific cases, e.g. when a module is imported once for an optional feature. It seems to be the case currently for coordinates inside nddata, at least currently, as Cutout is not used in the nddata classes. Actually Cutout and the other stuff in nddata.utils is not used anywhere in nddata, so maybe the whole module could be somewhere else or not imported in nddata, but it may be difficult to change this now. Anyway, @MSeifert04 and others know better that me about nddata and what is planned for this package, so it is just a suggestion ;).

[mwcraig]

Labelled as nddata in the hopes we remember to look at it in a couple weeks...