On Sun, Jul 23, 2017, 10:52 Michel Desmoulin, <desmoulinmic...@gmail.com> wrote:
> > > Le 23/07/2017 à 19:36, Brett Cannon a écrit : > > > > > > On Sun, Jul 23, 2017, 00:53 Michel Desmoulin, <desmoulinmic...@gmail.com > > <mailto:desmoulinmic...@gmail.com>> wrote: > > > > > > > > > Optimizing startup time is incredibly valuable, > > > > I've been reading that from the beginning of this thread but I've > been > > using python since the 2.4 and I never felt the burden of the > > startup time. > > > > I'm guessing a lot of people are like me, they just don't express > them > > self because "better startup time can't be bad so let's not put a > > barrier on this". > > > > I'm not against it, but since the necessity of a faster Python in > > general has been a debate for years and is only finally catching up > with > > the work of Victor Stinner, can somebody explain me the deal with > start > > up time ? > > > > I understand where it can improve your lives. I just don't get why > it's > > suddenly such an explosion of expectations and needs. > > > > > > It's actually always been something we have tried to improve, it just > > comes in waves. For instance we occasionally re-examine what modules get > > pulled in during startup. Importlib was optimized to help with startup. > > This just happens to be the latest round of trying to improve the > situation. > > > > As for why we care, every command-line app wants to at least appear > > faster if not be faster because just getting to the point of being able > > to e.g. print a version number is dominated by Python and app start-up. > > > Fair enought. > > > And this is not guessing; I work with a team that puts out a command > > line app and one of the biggest complaints they get is the startup time. > > This I don't get. When I run any command line utility in python (grin, > ffind, pyped, django-admin.py...), the execute in a split second. > > I can't even SEE the different between: > > python3 -c "import os; [print(x) for x in os.listdir('.')]" > > and > > ls . > > I'm having a hard time understanding how the Python VM startup time can > be perceived as a barriere here. I can understand if you have an > application firing Python 1000 times a second, like a CGI service or > some kind of code exec service. But scripting ? > So you're viewing it from a single OS and single machine perspective. Stuff varies so much that you can't compare something like this based on a single experience. I also said "appear" on purpose. 😉 Some people just compare Python against other languages based on benchmarks like startup when choosing a language so part of this is optics. This also applies when people compare Python 2 to 3. > Now I can imagine that a given Python program can be slow to start up, > because it imports a lot of things. But not the VM itself. > There's also the fact that some things we might do to speed up Python's own startup will propagate to user code and so have a bigger effect, e.g. making namedtuple cheaper reaches into user code that uses namedtuple. IOW based on experience this is worth the time to look into. > > > > > -brett > > > > _______________________________________________ > > Python-Dev mailing list > > Python-Dev@python.org <mailto:Python-Dev@python.org> > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > > https://mail.python.org/mailman/options/python-dev/brett%40python.org > > >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com