[Python-Dev] Python startup time

[Brett Cannon]

On Sun, Jul 23, 2017, 10:52 Michel Desmoulin, <desmoulinmichel at gmail.com>
wrote:

>
>
> Le 23/07/2017 à 19:36, Brett Cannon a écrit :
> >
> >
> > On Sun, Jul 23, 2017, 00:53 Michel Desmoulin, <desmoulinmichel at gmail.com
> > <mailto:desmoulinmichel at 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 at python.org <mailto:Python-Dev at python.org>
> >     https://mail.python.org/mailman/listinfo/python-dev
> >     Unsubscribe:
> >
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170723/86e0cf21/attachment.html>