4 ms·

How do you mean, python is slow to start up? $ time python -c 'exit()' python -c 'exit()' 0.01s user 0.01s system 98% cpu 0.021 total Seems pretty fa

How do you mean, python is slow to start up? $ time python -c 'exit()' python -c 'exit()' 0.01s user 0.01s system 98% cpu 0.021 total Seems pretty fast to me... And though python is no speed daemon, for a scripting/embedded language, it's likely to be fast enough.

mehrdadn 7y ago
10ms is already ridiculous for a program that just call exit(). Now try importing some stuff, and also testing a little more thoroughly... > python3 -c "import sys, timeit; n = 10; print('%.2f ms/spawn' % (1000 * timeit.timeit('subprocess.call([%r, %r, %r], stdin=subprocess.DEVNULL)' % (sys.executable, '-c', 'import re, argparse, subprocess'), 'import subprocess', number=n) / n))" Ubuntu (native): 20.82 ms/spawn Ubuntu (WSL): 43.16 ms/spawn Windows: 89.45 ms/spawn (without imports: 74 ms/spawn) For reference on Windows, here's PHP, taking half the time to start up: > python3 -c "import sys, timeit; n = 10; print('%.2f ms/spawn' % (1000 * timeit.timeit('subprocess.call([%r, %r, %r], stdin=subprocess.DEVNULL)' % ('php', '-R', ''), 'import subprocess', number=n) / n))" 45.14 ms/spawn Now consider that you'll generally be doing a LOT more on initialization than just importing these packages, a lot of packages end up being extremely heavyweight, and very likely you'll be calling Python several times in a row... it can easily waste seconds on startup, even on Linux.
- earenndil 7y ago
  First off, WSL and MSYS2's startup time isn't really fair to compare, since if you're running on windows you're probably going to be running native python. Especially if you're using the kind of application that has scripts/plug-ins. I don't currently have a windows machine to test that, but I imagine you do since you just timed it. I also don't agree that 10ms is ridiculous. That's barely any time at all. That's less than a frame, at 60Hz. And, how many interpreter instances are you going to start up? Surely, no more instances than you have cores; that means, worst-case scenario if you have a ryzen threadripper or a maxed-out POWER9 (both have 96 cores), a second. For most people, it's going to take under half a second; considering most programs take tens of seconds to start up, I think that's fine. Not to mention that if you have 'complex initialization code', that's going to take a long time regardless of language; what we're testing the the language core baseline startup time.
  - mehrdadn 7y ago
    WSL is fair, MSYS2 isn't. That's why I took out MSYS2 as I was revising my comment. The timings I have now are just WSL and plain, native Windows. And the number of interpreters you spawn isn't a function of cores either. It depends entirely what you're doing, and nobody was talking about parallel execution. If you run a bunch of Python scripts in sequence you'll multiply the startup overhead... I guess we'll just have to disagree on 10ms being ridiculous for a program that does nothing. To me it is. And half a second is orders of magnitude more so. P.S. All of this is my timing on a pretty darn fast CPU. Try running on a more typical laptop CPU, switching to battery, and you'll get even worse timing.
    - earenndil 7y ago
      If you're running a bunch of scripts in sequence, you should have a single interpreter state you use for running all of them. I would do that even if startup were effectively free. And yeah, I have only a crappy laptop and your benchmark takes more like 50ms/spawn for me. Which I still think is reasonable because there's no reason to make a new interpreter state for ever script.
      - mehrdadn 7y ago
        Your question was "how is Python slow?" where you were apparently arguing over the slowness of standalone Python. For an embedded application, of course you'd try to keep the interpreter state if it's possible. Sometimes you can't because of global state changes; sometimes you can. And sometimes, even with a single interpreter, the rest of the C++ program is fast enough that the embedded Python initialization time would dominate its running time, rendering the standalone vs. embedded distinction moot. In any case... all you're doing is amortizing slow startup cost over the lifetime of the program. The startup is still slow. You were wondering "how" the startup is slow, so I wrote you benchmarks and ran them to illustrate. If what you really wanted to argue was that startup time is irrelevant, maybe you should say that instead of asking "how is startup slow" and making me spend my time writing a benchmark for something you don't care about.
- earenndil 7y ago
  By the by, why does your python example import a bunch of things, but the php code imports nothing? That would negate the entire purpose of the experiment, no...
  - mehrdadn 7y ago
    Because, there wasn't anything to import?! preg_match(), getopt(), system(), etc. are already available... if anything, you should be asking why I'm unfairly penalizing PHP by comparing it against a no-import Python! And I did give you an example of Python that doesn't import anything, and as you can see (and could have easily tested yourself) it was still a lot slower...
    - earenndil 7y ago
      Python not importing anything is the same speed as php not importing anything on my system. Oh, and--incidentally, javascript is 20% faster than php and python both, and afaik you don't have to import libraries there either.
      - mehrdadn 7y ago
        Yes, so that means Python is slower to start on your system too. Not sure what you mean by "Javascript"... what program are you running?
        earenndil 7y ago
        Javascriptcore; jsc. It's part of webkit (comes from the webkit2gtk package on my system).
        mehrdadn 7y ago
        Oh I see. Cool. Now compare with Lua: $ python3 -c "import sys, timeit; n = 10; print('%.2f ms/spawn' % (1000 * timeit.timeit('subprocess.call([%r, %r], stdin=subprocess.DEVNULL, stdout=subprocess.DEVNULL)' % ('lua', '-'), 'import subprocess', number=n) / n))" 1.09 ms/spawn NewLisp: $ python3 -c "import sys, timeit; n = 10; print('%.2f ms/spawn' % (1000 * timeit.timeit('subprocess.call([%r, %r], stdin=subprocess.DEVNULL, stdout=subprocess.DEVNULL)' % ('newlisp', '-'), 'import subprocess', number=n) / n))" 1.25 ms/spawn
- mixmastamyk 7y ago
  python3 -S To bypass unnecessary startup stuff.
  - mehrdadn 7y ago
    I'm indeed aware, but it doesn't change the conclusion, and I was trying to keep things consistent with the parent comment. All that does is reduce 89ms to 55ms.
    - mixmastamyk 7y ago
      That's a significant improvement. Believe latest versions have been working on this number as well.
      - mehrdadn 7y ago
        Not saying it's insignificant, just saying it doesn't change the conclusion.

mehrdadn 7y ago

10ms is already ridiculous for a program that just call exit(). Now try importing some stuff, and also testing a little more thoroughly... > python3 -c "import sys, timeit; n = 10; print('%.2f ms/spawn' % (1000 * timeit.timeit('subprocess.call([%r, %r, %r], stdin=subprocess.DEVNULL)' % (sys.executable, '-c', 'import re, argparse, subprocess'), 'import subprocess', number=n) / n))" Ubuntu (native): 20.82 ms/spawn Ubuntu (WSL): 43.16 ms/spawn Windows: 89.45 ms/spawn (without imports: 74 ms/spawn) For reference on Windows, here's PHP, taking half the time to start up: > python3 -c "import sys, timeit; n = 10; print('%.2f ms/spawn' % (1000 * timeit.timeit('subprocess.call([%r, %r, %r], stdin=subprocess.DEVNULL)' % ('php', '-R', ''), 'import subprocess', number=n) / n))" 45.14 ms/spawn Now consider that you'll generally be doing a LOT more on initialization than just importing these packages, a lot of packages end up being extremely heavyweight, and very likely you'll be calling Python several times in a row... it can easily waste seconds on startup, even on Linux.

earenndil 7y ago
First off, WSL and MSYS2's startup time isn't really fair to compare, since if you're running on windows you're probably going to be running native python. Especially if you're using the kind of application that has scripts/plug-ins. I don't currently have a windows machine to test that, but I imagine you do since you just timed it. I also don't agree that 10ms is ridiculous. That's barely any time at all. That's less than a frame, at 60Hz. And, how many interpreter instances are you going to start up? Surely, no more instances than you have cores; that means, worst-case scenario if you have a ryzen threadripper or a maxed-out POWER9 (both have 96 cores), a second. For most people, it's going to take under half a second; considering most programs take tens of seconds to start up, I think that's fine. Not to mention that if you have 'complex initialization code', that's going to take a long time regardless of language; what we're testing the the language core baseline startup time.
- mehrdadn 7y ago
  WSL is fair, MSYS2 isn't. That's why I took out MSYS2 as I was revising my comment. The timings I have now are just WSL and plain, native Windows. And the number of interpreters you spawn isn't a function of cores either. It depends entirely what you're doing, and nobody was talking about parallel execution. If you run a bunch of Python scripts in sequence you'll multiply the startup overhead... I guess we'll just have to disagree on 10ms being ridiculous for a program that does nothing. To me it is. And half a second is orders of magnitude more so. P.S. All of this is my timing on a pretty darn fast CPU. Try running on a more typical laptop CPU, switching to battery, and you'll get even worse timing.
  - earenndil 7y ago
    If you're running a bunch of scripts in sequence, you should have a single interpreter state you use for running all of them. I would do that even if startup were effectively free. And yeah, I have only a crappy laptop and your benchmark takes more like 50ms/spawn for me. Which I still think is reasonable because there's no reason to make a new interpreter state for ever script.
    - mehrdadn 7y ago
      Your question was "how is Python slow?" where you were apparently arguing over the slowness of standalone Python. For an embedded application, of course you'd try to keep the interpreter state if it's possible. Sometimes you can't because of global state changes; sometimes you can. And sometimes, even with a single interpreter, the rest of the C++ program is fast enough that the embedded Python initialization time would dominate its running time, rendering the standalone vs. embedded distinction moot. In any case... all you're doing is amortizing slow startup cost over the lifetime of the program. The startup is still slow. You were wondering "how" the startup is slow, so I wrote you benchmarks and ran them to illustrate. If what you really wanted to argue was that startup time is irrelevant, maybe you should say that instead of asking "how is startup slow" and making me spend my time writing a benchmark for something you don't care about.
earenndil 7y ago
By the by, why does your python example import a bunch of things, but the php code imports nothing? That would negate the entire purpose of the experiment, no...
- mehrdadn 7y ago
  Because, there wasn't anything to import?! preg_match(), getopt(), system(), etc. are already available... if anything, you should be asking why I'm unfairly penalizing PHP by comparing it against a no-import Python! And I did give you an example of Python that doesn't import anything, and as you can see (and could have easily tested yourself) it was still a lot slower...
  - earenndil 7y ago
    Python not importing anything is the same speed as php not importing anything on my system. Oh, and--incidentally, javascript is 20% faster than php and python both, and afaik you don't have to import libraries there either.
    - mehrdadn 7y ago
      Yes, so that means Python is slower to start on your system too. Not sure what you mean by "Javascript"... what program are you running?
      - earenndil 7y ago
        Javascriptcore; jsc. It's part of webkit (comes from the webkit2gtk package on my system).
        mehrdadn 7y ago
        Oh I see. Cool. Now compare with Lua: $ python3 -c "import sys, timeit; n = 10; print('%.2f ms/spawn' % (1000 * timeit.timeit('subprocess.call([%r, %r], stdin=subprocess.DEVNULL, stdout=subprocess.DEVNULL)' % ('lua', '-'), 'import subprocess', number=n) / n))" 1.09 ms/spawn NewLisp: $ python3 -c "import sys, timeit; n = 10; print('%.2f ms/spawn' % (1000 * timeit.timeit('subprocess.call([%r, %r], stdin=subprocess.DEVNULL, stdout=subprocess.DEVNULL)' % ('newlisp', '-'), 'import subprocess', number=n) / n))" 1.25 ms/spawn
mixmastamyk 7y ago
python3 -S To bypass unnecessary startup stuff.
- mehrdadn 7y ago
  I'm indeed aware, but it doesn't change the conclusion, and I was trying to keep things consistent with the parent comment. All that does is reduce 89ms to 55ms.
  - mixmastamyk 7y ago
    That's a significant improvement. Believe latest versions have been working on this number as well.
    - mehrdadn 7y ago
      Not saying it's insignificant, just saying it doesn't change the conclusion.