> > But is the startup time of apps that use a lot of stuff the most > > important thing? I'd say that the startup time of apps that *don't* > > use a lot of stuff is more important. I'm not sure that making the > > binary bigger doesn't slow it down. > > I'm pretty sure that it doesn't. On Unix, the system performs a > copy-on-write mmap of the executable. No disk access is done until > page faults trigger a disk read. I believe Windows uses a similar > mechanism. The size of the executable is irrelevant (if you have no > relocations); only the part of the executable that is used matters. > > On the other hand, on my Linux installation, importing a module costs > 35 system calls if the module is not found, and no PYTHONPATH is set; > every directory in PYTHONPATH adds four additional system calls. > > > Yes, please. We switched to building almost all extensions as shared > > libs when we switched away from Modules/Setup to setup.py. > > For modules that require configuration, this was a good thing - now > setup.py will autoconfigure them. For modules that require no > additional libraries, I hope that this decision will be reverted some > day. If other people feel the same way, I won't stop progress here. But I find startup time a rather uninteresting detail, and everything else being the same I would personally prefer to keep the status quo: not because it's better, but because it's the status quo. Why churn? --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4