Le 23/07/2017 à 19:36, Brett Cannon a écrit :
>
>
> On Sun, Jul 23, 2017, 00:53 Michel Desmoulin, <desmoulinmichel@gmail.com
> <mailto:desmoulinmichel@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.