Comment by cjhanks
8 years ago
As expected, language start up time only matters to some people. Often in my case, Python is used to build command line tools (similar to the case of Mercurial).
In such an event, the start-up time of the program might dominate the total run time of the application. And on my laptop or desktop with a fast SSD with good caching and a reasonably fast CPU... that still ends up being 'okay'.
But once I put that on an ARM chip with a mediocre hard drive - some python scripts spend so long initializing that they are practically unusable. Whereas the comparable Perl/BASH script runs almost instantaneously.
Often to make Python even practically usable for such systems I have to implement my own lazily loaded module system. Having some language which allowed me to say...
import(eager) some_module
import(lazy) another_module
Which could trigger the import process only when that module becomes necessary (if ever).
Have you tried moving import statements into the functions where they are invoked? My understanding is this is effectively the same as lazy loading the module[1].
[1] https://stackoverflow.com/questions/3095071/in-python-what-h...
I have, and it actually works well (performance wise). The maintenance burden is a little higher.
A little Python preprocessor that lets you annotate your lazy modules sounds like a fun little toy project, actually. Not something I'd use for real, but it would be fun to build.
1 reply →
Python is moving to have a lazy loader as part of the standard library. I mean, it's there already, at https://docs.python.org/3/library/importlib.html#importlib.u... , but not clearly easy to use, and with a big warning label against using it.
The issue at https://bugs.python.org/issue32192 says the plan is to start with an easier to use system as a PyPI package.
I've also written a little asynchronous module loading system. Why not load a module we know we're going to need in the background?