6 ms·

More important than the optimizations themselves is the instrumentation they built up to reliably measure and monitor the performance. One thing to keep in min

More important than the optimizations themselves is the instrumentation they built up to reliably measure and monitor the performance. One thing to keep in mind is that python 3 is still considerably slower than python 2 (edit) in some areas such as startup times while it has gotten faster in most other benchmarks.

joshuamorton 9y ago
Its worth watching the video in its entirety. That's not true. Python 3.6 beats 2.7 in most benchmarks, its just that there are a few places where 3 is slower (like startup time) that make a lot of things look bad, but that don't actually affect "speed" as most people would consider.
- gshulegaard 9y ago
  This is the right answer. > One thing to keep in mind is that python 3 is still considerably slower than python 2. IIRC this statement started to shift ~3.4. There are still areas where 2.7 is faster, but it is more of a gray area than black and white like it used to be.
- dman 9y ago
  The startup time fiasco was one of the reasons why Java never took over for GUI apps. Even though its unscientific, time to first usable interaction goes a long way in establishing "speed" in the users mind. You should see the hoops that Chrome jumps through to excel on this metric.
  - kstrauser 9y ago
    True, but: $ echo exit | time python2 gives an average time of 0.015s on my laptop, and $ echo exit | time python3 works out to about 0.039s. If you're spamming hundreds of processes from a looping shell script, the Python 3 overhead would probably start to grate. For anything manually launched, 40 milliseconds is still substantially close to instant.
    - philipov 9y ago
      > If you're spamming hundreds of processes from a looping shell script, You should absorb the loop into a single python process that instead calls the original script as a library...
      - Too 9y ago
        Mercurial has another approach. They have something called command server launched once and communicati g over socket if you need to invoke it thousands of times. If start up time is a problem with python your biggest problem is start up time with python, not the difference between 2 and 3.
    - microcolonel 9y ago
      and I would point out that on my machine (GCC 6.3-based x86-64 Linux) the times are much closer ~ time python2 -c exit real 0m0.014s user 0m0.011s sys 0m0.004s vs. ~ time python3 -c exit real 0m0.022s user 0m0.018s sys 0m0.004s So for me it's more like an 8ms realtime difference, and four milliseconds are spent in the system either way. python2 seems to do about 700 system calls (!) to start up and exit immediately, including enumerating things like gtk-2 and wxwidgets, which boggles the mind, but it is what it is. python3 seems to do about 470 system calls, much less but still bonkers to my mind. Also weird that they take the same ~4ms in the kernel given that python3 calls into the kernel so much less.
      - kstrauser 9y ago
        That's better yet - thanks for sharing! Most of my Python processes run for weeks at a go, so startup time isn't that important to me as long as it's not glacial. But 40ms (on my system) or 22ms (on yours) is totally acceptable for interactive shell usage. Thanks for including the syscall counts. I know they'd been working to reduce that, but I hadn't seen how much progress they'd made yet. Are most of those to malloc() and open()?
        joshuamorton 9y ago
- dr_zoidberg 9y ago
  I have a codebase at work (which arguably was optimized for 2.7) that is about 2-5% percent slower when running in Py3* . It's not a huge slowdown, but it is consistent. Hope 3.7 finally puts it on par (or faster) than 2.7, but we've decided to migrate with 3.6 anyway. Don't take me wrong, I like having finally put 2.x behind, but it still bothers me a bit. Maybe we just have to get used to optimizing the "3.x series". * this has been measured without startup time, just function calls, with horrible datetime.datetime.now() timings and %timeit magic-keyword from IPython -- always consistent.
mundanevoice 9y ago
> One thing to keep in mind is that python 3 is still considerably slower than python 2. You have wrong information.
- jayflux 9y ago
  > The net result of the 3.0 generalizations is that Python 3.0 runs the pystone benchmark around 10% slower than Python 2.5. Most likely the biggest cause is the removal of special-casing for small integers. There’s room for improvement, but it will happen after 3.0 is released! https://docs.python.org/release/3.0.1/whatsnew/3.0.html https://docs.python.org/release/3.0.1/whatsnew/3.0.html
  - rplnt 9y ago
    Here's the full benchmark suite from speed.python.org showing what is faster and what is slower in 3.6 as compared to 2.7: https://speed.python.org/comparison/?exe=12%2BL%2B3.6%2C12%2BL%2B2.7&ben=616%2C617%2C618%2C619%2C620%2C621%2C622%2C623%2C624%2C625%2C626%2C627%2C628%2C629%2C630%2C631%2C632%2C680%2C633%2C634%2C635%2C636%2C637%2C638%2C639%2C640%2C641%2C642%2C643%2C644%2C645%2C646%2C647%2C648%2C681%2C649%2C650%2C651%2C652%2C653%2C654%2C655%2C656%2C657%2C658%2C659%2C660%2C661%2C682%2C662%2C663%2C664%2C665%2C666%2C667%2C669%2C668%2C670%2C671%2C672%2C673%2C674%2C675%2C678%2C677%2C676%2C679&env=1&hor=true&bas=12%2BL%2B2.7&chart=normal+bars https://speed.python.org/comparison/?exe=12%2BL%2B3.6%2C12%2... It would be very hard for someone to say "python 3 is considerably slower". Startup is significantly slower, yes, but that's about it.
    - dom0 9y ago
      It's not like it should surprise anyone. The import machinery in Python 2 was mostly written in C, while it's pure Python in Python 3. And if you've seen what that stuff does it's no surprise that even fairly small applications can take .1-.2 s to reach main. A tool gathering imports in one file if it is safe to do so would be really quite neat for deploying interactive Python applications (command line / GUIs). On the more extreme end you'd have a C application linking not too many libraries (symbols are lazily loaded, libraries are not) that reaches main after 0.0001-0.0002 s (i.e. one to two hundred µs). On the other extreme would be Java apps using heavy runtime-code-generating frameworks like Spring, where even a trivial app can take up to ten seconds to spring to life.
masklinn 9y ago
> One thing to keep in mind is that python 3 is still considerably slower than python 2. The video quite definitely states otherwise for most benchmarks. Only a few benches still show regressions over P2, and according to Victor they're unlikely to affect the vast majority of systems.
- baldfat 9y ago
  I wished this Python 2 and Python 3 was done with more carrot and whip to move people over to 3. It has been over a decade and we still have divided community.
  - infogulch 9y ago
    It's gained much more momentum over just the last year from what I can see.
  - sametmax 9y ago
    The community is not divided anymore. Anybody who knows wants to use 3. Anybody who doesn't is told to. The only people using Python 2 are now people stuck with legacy code base. It's an important part, but the situation is very clear.
    - user5994461 9y ago
      The situation is very clear, any code base that is older than 5 years and more than a million lines will be forever stuck with python 2.
    - sandGorgon 9y ago
      > The only people using Python 2 are now people stuck with legacy code base Like tensorflow - https://github.com/tensorflow/tensorflow/issues/1 https://github.com/tensorflow/tensorflow/issues/1
      - chronial 9y ago
        You do realize that that issue was closed in 2015, right?

joshuamorton 9y ago

Its worth watching the video in its entirety. That's not true. Python 3.6 beats 2.7 in most benchmarks, its just that there are a few places where 3 is slower (like startup time) that make a lot of things look bad, but that don't actually affect "speed" as most people would consider.

gshulegaard 9y ago
This is the right answer. > One thing to keep in mind is that python 3 is still considerably slower than python 2. IIRC this statement started to shift ~3.4. There are still areas where 2.7 is faster, but it is more of a gray area than black and white like it used to be.
dman 9y ago
The startup time fiasco was one of the reasons why Java never took over for GUI apps. Even though its unscientific, time to first usable interaction goes a long way in establishing "speed" in the users mind. You should see the hoops that Chrome jumps through to excel on this metric.
- kstrauser 9y ago
  True, but: $ echo exit | time python2 gives an average time of 0.015s on my laptop, and $ echo exit | time python3 works out to about 0.039s. If you're spamming hundreds of processes from a looping shell script, the Python 3 overhead would probably start to grate. For anything manually launched, 40 milliseconds is still substantially close to instant.
  - philipov 9y ago
    > If you're spamming hundreds of processes from a looping shell script, You should absorb the loop into a single python process that instead calls the original script as a library...
    - Too 9y ago
      Mercurial has another approach. They have something called command server launched once and communicati g over socket if you need to invoke it thousands of times. If start up time is a problem with python your biggest problem is start up time with python, not the difference between 2 and 3.
  - microcolonel 9y ago
    and I would point out that on my machine (GCC 6.3-based x86-64 Linux) the times are much closer ~ time python2 -c exit real 0m0.014s user 0m0.011s sys 0m0.004s vs. ~ time python3 -c exit real 0m0.022s user 0m0.018s sys 0m0.004s So for me it's more like an 8ms realtime difference, and four milliseconds are spent in the system either way. python2 seems to do about 700 system calls (!) to start up and exit immediately, including enumerating things like gtk-2 and wxwidgets, which boggles the mind, but it is what it is. python3 seems to do about 470 system calls, much less but still bonkers to my mind. Also weird that they take the same ~4ms in the kernel given that python3 calls into the kernel so much less.
    - kstrauser 9y ago
      That's better yet - thanks for sharing! Most of my Python processes run for weeks at a go, so startup time isn't that important to me as long as it's not glacial. But 40ms (on my system) or 22ms (on yours) is totally acceptable for interactive shell usage. Thanks for including the syscall counts. I know they'd been working to reduce that, but I hadn't seen how much progress they'd made yet. Are most of those to malloc() and open()?
      - joshuamorton 9y ago
dr_zoidberg 9y ago
I have a codebase at work (which arguably was optimized for 2.7) that is about 2-5% percent slower when running in Py3* . It's not a huge slowdown, but it is consistent. Hope 3.7 finally puts it on par (or faster) than 2.7, but we've decided to migrate with 3.6 anyway. Don't take me wrong, I like having finally put 2.x behind, but it still bothers me a bit. Maybe we just have to get used to optimizing the "3.x series". * this has been measured without startup time, just function calls, with horrible datetime.datetime.now() timings and %timeit magic-keyword from IPython -- always consistent.

mundanevoice 9y ago

> One thing to keep in mind is that python 3 is still considerably slower than python 2. You have wrong information.

jayflux 9y ago
> The net result of the 3.0 generalizations is that Python 3.0 runs the pystone benchmark around 10% slower than Python 2.5. Most likely the biggest cause is the removal of special-casing for small integers. There’s room for improvement, but it will happen after 3.0 is released! https://docs.python.org/release/3.0.1/whatsnew/3.0.html https://docs.python.org/release/3.0.1/whatsnew/3.0.html
- rplnt 9y ago
  Here's the full benchmark suite from speed.python.org showing what is faster and what is slower in 3.6 as compared to 2.7: https://speed.python.org/comparison/?exe=12%2BL%2B3.6%2C12%2BL%2B2.7&ben=616%2C617%2C618%2C619%2C620%2C621%2C622%2C623%2C624%2C625%2C626%2C627%2C628%2C629%2C630%2C631%2C632%2C680%2C633%2C634%2C635%2C636%2C637%2C638%2C639%2C640%2C641%2C642%2C643%2C644%2C645%2C646%2C647%2C648%2C681%2C649%2C650%2C651%2C652%2C653%2C654%2C655%2C656%2C657%2C658%2C659%2C660%2C661%2C682%2C662%2C663%2C664%2C665%2C666%2C667%2C669%2C668%2C670%2C671%2C672%2C673%2C674%2C675%2C678%2C677%2C676%2C679&env=1&hor=true&bas=12%2BL%2B2.7&chart=normal+bars https://speed.python.org/comparison/?exe=12%2BL%2B3.6%2C12%2... It would be very hard for someone to say "python 3 is considerably slower". Startup is significantly slower, yes, but that's about it.
  - dom0 9y ago
    It's not like it should surprise anyone. The import machinery in Python 2 was mostly written in C, while it's pure Python in Python 3. And if you've seen what that stuff does it's no surprise that even fairly small applications can take .1-.2 s to reach main. A tool gathering imports in one file if it is safe to do so would be really quite neat for deploying interactive Python applications (command line / GUIs). On the more extreme end you'd have a C application linking not too many libraries (symbols are lazily loaded, libraries are not) that reaches main after 0.0001-0.0002 s (i.e. one to two hundred µs). On the other extreme would be Java apps using heavy runtime-code-generating frameworks like Spring, where even a trivial app can take up to ten seconds to spring to life.

masklinn 9y ago

> One thing to keep in mind is that python 3 is still considerably slower than python 2. The video quite definitely states otherwise for most benchmarks. Only a few benches still show regressions over P2, and according to Victor they're unlikely to affect the vast majority of systems.

baldfat 9y ago
I wished this Python 2 and Python 3 was done with more carrot and whip to move people over to 3. It has been over a decade and we still have divided community.
- infogulch 9y ago
  It's gained much more momentum over just the last year from what I can see.
- sametmax 9y ago
  The community is not divided anymore. Anybody who knows wants to use 3. Anybody who doesn't is told to. The only people using Python 2 are now people stuck with legacy code base. It's an important part, but the situation is very clear.
  - user5994461 9y ago
    The situation is very clear, any code base that is older than 5 years and more than a million lines will be forever stuck with python 2.
  - sandGorgon 9y ago
    > The only people using Python 2 are now people stuck with legacy code base Like tensorflow - https://github.com/tensorflow/tensorflow/issues/1 https://github.com/tensorflow/tensorflow/issues/1
    - chronial 9y ago
      You do realize that that issue was closed in 2015, right?