gkreidl
Posts: 5200
Joined: Thu Jan 26, 2012 1:07 pm
Location: Germany

Python speed, benchmarks, 2v3

Tue May 16, 2017 3:32 pm

While converting some of my Python 2 scripts to Python 3 I discovered notable performance differences. So I became interested in benchmarking Python 2 and 3. I also use Nuitka ( http://nuitka.net/ ) to compile some of my Python stuff to binaries for different reasons (speed may be one of them).

Here are the results of the Pystone benchmarks for Python 2.7 and 3.4 and for compiled programs of both verions. Except for the time measurement the Pystone benchmark only uses functions built into the main Python library.

Python 2.7: 24344.88 pystones/second
Python 3.4: 17459.89 pystones/second
Nuitka 2.7: 47243.92 pystones/second
Nuitka 3.4: 28658.92 pystones/second

Speed Comparisons:

Python 2.7 / Python 3.4: 139.43 %
Nuitka 2.7 / Python 2.7: 194.06 %
Nuitka 3.4 / Python 3.4: 164.14 %
Nuitka 2.7 / Nuitka 3.4: 164.85 %
Nuitka 2.7 / Python 3.4: 270.59 %

Obviously Python 2.7 runs almost 40% faster than Python 3.4 code. The speed gain when compiling it with Nuitka is also greater for 2.7: 94% instead of 64%. And a compiled Python 2.7 program runs 2.7 times faster than an interpreted Python 3.4 script.

Does than mean, that you should use Python 2.7 instead of 3.4? For beginners and new (long time) projects I would not recommend it. For many projects, speed is not an issue at all. Inside a GUI for example, most of the time is spent waiting for user input or user events. And often it is better to look for Python wrappers of compiled C libraries for time critical stuff.

But if your project contains time critical Python routines, you might consider writing code that will run on both Python 2.7 and Python 3.4. That's not an easy task, but there are a number of tools available which help a lot. The best I found is the "future" package from http://python-future.org (can be installed using pip and pip3). This website also provides a great "Cheat Sheet" which shows how to write code that will run on both Python versions (also available as PDF document http://python-future.org/compatible_idioms.pdf ). The "future" package also contains two great utilities: "futurize" ( to help converting 2.7 to 3.4) and "pasteurize" (to help creating 2.7 compatible code from 3.4 sources).

There's one drawback, though: if you want to distribute your code, you must make sure, that the "future" package is installed. Unfortunately it is not available as a Debian (Raspbian) package and so it's not possible to add it as a dependency to a Debian package.

Other tools: Cython and PyPy.

I've also compiled pystone with Cython (2.7 only), but got only about 10% speed gain. So it's not really worth the effort. Adding Cython specific code might help, but I didn't try that.

Often PyPy is recommended to speed up Python code using a JIT compiler. The Pystone benchmark gives different results, depending on the number of loops:
1000 loops: 5770.32 pystones/second (slower than 2.7 interpreter)
5000 loops: 27645.2 pystones/second (slightly faster than 2.7 interpreter)
10000 loops: 52145.1 pystones/second (faster than 2.7 compiled with Nuitka)
100000 loops: 248133 pystones/second (really much faster!).

Currently PyPy is only available on the RPi for Python 2.7. Using it in real world applications may lead to difficulties because of its memory usage. For my DVB application I needed a script to extract EPG information in real time from a DVB stream (up to 10 MBit/sec). I found a script from another project, which worked quite well, but needed some speed improvement. I ended up in running it as a separate application (compiled with Nuitka as 2.7 code), to make sure it will run on a separate core. I also tested using it with PyPy. It seemed to work fine, but my system almost froze after a short while (starting to swap). Watching the memory I discovered that it used up to 480 MB, while the compiled Nuitka script never used more than about 70 MB. Fast, yes, but not usable.
Minimal Kiosk Browser (kweb)
Slim, fast webkit browser with support for audio+video+playlists+youtube+pdf+download
Optional fullscreen kiosk mode and command interface for embedded applications
Includes omxplayerGUI, an X front end for omxplayer

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 17765
Joined: Sat Jul 30, 2011 7:41 pm

Re: Python speed, benchmarks, 2v3

Tue May 16, 2017 3:41 pm

That's pretty interesting. I did some quick tests the other day (after your suggestion of compiling Pythin with nuitka), and found much the same. Python 3.4 is pretty slow compared with older version. My nuitka compiles didn't show anywhere near that speed improvement though, but the program was very simple.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

bensimmo
Posts: 1694
Joined: Sun Dec 28, 2014 3:02 pm
Location: East Yorkshire

Re: Python speed, benchmarks, 2v3

Tue May 16, 2017 4:03 pm

How does 3.5 compare (in stretch)?
3.4 may well be lagging in optimizations especially when 3.6.1 is the current latest version.

hippy
Posts: 2169
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Python speed, benchmarks, 2v3

Tue May 16, 2017 5:48 pm

bensimmo wrote:How does 3.5 compare (in stretch)?
3.4 may well be lagging in optimizations especially when 3.6.1 is the current latest version.
I did try some simplistic benchmarking and was getting the same '2.7 is quite a lot faster than 3.4' results consistent with other reports and benchmarks. I also tried 3.6.0 with the same simplistic benchmarks and that seems to somewhat improve on 3.4 but still not as fast as 2.7. Have not tried 3.6.1 -

viewtopic.php?f=32&t=172622&p=1104397#p1104397

hippy
Posts: 2169
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Python speed, benchmarks, 2v3

Tue May 16, 2017 6:10 pm

gkreidl wrote:Does than mean, that you should use Python 2.7 instead of 3.4? For beginners and new (long time) projects I would not recommend it. For many projects, speed is not an issue at all. Inside a GUI for example, most of the time is spent waiting for user input or user events.
That is a difficult question to answer. I would however also recommend new users start with Python 3, though through gritted teeth.

For myself I am sticking with 2.7. I tend to throw code together on a Windows PC, get that working, then copy to my Pi and run there. Most of my Python code is input-process-output-exit, isn't execution speed critical as such, but if it takes more than a second or two to run and return to the command prompt it can feel slow, and 3.4 can often make things feel too slow.

I will optimise my code when I need or want to improve things, but quite a lot of optimisation may need to be done for 3.4 just to get to 2.7 speed. Might as well use 2.7 to start with.

For a couple of GUI programs I wrote there is nothing much in it. As you note; code like that is mostly waiting for input.

Added : One trick for making a slow program feel quicker; output a progress bar. It is amazing how a progress bar seems to make things run quicker even though it changes nothing

bensimmo
Posts: 1694
Joined: Sun Dec 28, 2014 3:02 pm
Location: East Yorkshire

Re: Python speed, benchmarks, 2v3

Tue May 16, 2017 8:07 pm

Does the slowness stay if using your PC (say the ixel x86 version.)

This is all just interest (learning) as I don't know enough about the language and background in them.
There was a thread and somebody mentioned it may/was due to the way Python3 handles some of the numbers but I might be wrong.

Also everything on the Python website seems to be x86 targeted (windows and osx) does any optimization happen for Arm machines?

hippy
Posts: 2169
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Python speed, benchmarks, 2v3

Tue May 16, 2017 8:18 pm

bensimmo wrote:Does the slowness stay if using your PC (say the ixel x86 version.)
Yes; from testing it myself and everything I have read agrees that 3.4 is considerably slower than 2.7 on any platform. Some put that down to the way integers are handled / enumerated / whatever, but there seems to be more to it than just that. Text file output seemed considerably slower.

I benchmarked microPython on the Pi, which is based on Python 3-dot-something and apparently has optimisations for handling integers. I can't find those benchmark timings now but I recall that got closer to 2.7 for my simplistic integer benchmark, about the same as 3.6 for the simplistic float benchmark.

gkreidl
Posts: 5200
Joined: Thu Jan 26, 2012 1:07 pm
Location: Germany

Re: Python speed, benchmarks, 2v3

Wed May 17, 2017 4:11 am

I also did the same tests on my x86 Ubuntu Desktop. The results are similar, but the speed improvement by compiling 3.4 with nuitka is smaller:

Python 2.7: 121038.5 pystones/second
Python 3.4: 86386.7 pystones/second
Nuitka 2.7: 233031.5 pystones/second
Nuitka 3.4: 116628.96 pystones/second

Speed Comparisons:

Python 2.7 / Python 3.4: 140.11 %
Nuitka 2.7 / Python 2.7: 192.53 %
Nuitka 3.4 / Python 3.4: 135.01 %
Nuitka 2.7 / Nuitka 3.4: 199.81 %
Nuitka 2.7 / Python 3.4: 269.75 %
Minimal Kiosk Browser (kweb)
Slim, fast webkit browser with support for audio+video+playlists+youtube+pdf+download
Optional fullscreen kiosk mode and command interface for embedded applications
Includes omxplayerGUI, an X front end for omxplayer

User avatar
paddyg
Posts: 1917
Joined: Sat Jan 28, 2012 11:57 am

Re: Python speed, benchmarks, 2v3

Wed Sep 13, 2017 10:58 am

@gkreidl Hi, thanks for pointing me here (better not to subvert @ozziepiuser's thread any more). I've not used pystone before but it certainly does give py2.7 a speed advantage over py3.5. Just to check my own sanity I reran recent programs and, although py2 often came out faster, it is by a much smaller margin (2% c.f. 16% for pystone on RPi). Interestingly, a 'one off' app I had used to generate some normal maps (using a function from Texture.py here) ran about 10% faster with py2.7 but if I excluded the import numpy and PIL.Image it ran 1% slower than py3.5. With the pystone test pypy runs 12x faster than py2.7 or py3.5 but it was significantly slower for all the real programs I tested. I suppose the message is 'beware of benchmarks' - check the actual app and choose accordingly.

PS I suspect there is a bit of a speed penalty simply by making code work with 2 as well as 3
PPS on RPi3 with latest stretch, 50,000 pystone loops I get py2.7=>17200, py3.5=>14400 (16% slower),
on laptop 50,000 pystone loops py2.7=>96000, py3.5=>89000 (9% slower)
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d

gkreidl
Posts: 5200
Joined: Thu Jan 26, 2012 1:07 pm
Location: Germany

Re: Python speed, benchmarks, 2v3

Wed Sep 13, 2017 12:10 pm

paddyg wrote:
Wed Sep 13, 2017 10:58 am
@gkreidl Hi, thanks for pointing me here (better not to subvert @ozziepiuser's thread any more). I've not used pystone before but it certainly does give py2.7 a speed advantage over py3.5. Just to check my own sanity I reran recent programs and, although py2 often came out faster, it is by a much smaller margin (2% c.f. 16% for pystone on RPi). Interestingly, a 'one off' app I had used to generate some normal maps (using a function from Texture.py here) ran about 10% faster with py2.7 but if I excluded the import numpy and PIL.Image it ran 1% slower than py3.5. With the pystone test pypy runs 12x faster than py2.7 or py3.5 but it was significantly slower for all the real programs I tested. I suppose the message is 'beware of benchmarks' - check the actual app and choose accordingly.

PS I suspect there is a bit of a speed penalty simply by making code work with 2 as well as 3
PPS on RPi3 with latest stretch, 50,000 pystone loops I get py2.7=>17200, py3.5=>14400 (16% slower),
on laptop 50,000 pystone loops py2.7=>96000, py3.5=>89000 (9% slower)
HI Paddy!
The benchmark tests have been done on Jessie (and I got similar results on my x86 Desktop running Ubuntu 14.04).
You are right, benchmarks don't tell us everything. I used Pystone because the Nuitka developers mentioned it and have been using it.
I became interested in the difference when I rewrote my youtube-dl-server in Python3 and noticed that it started considerably slower.
Minimal Kiosk Browser (kweb)
Slim, fast webkit browser with support for audio+video+playlists+youtube+pdf+download
Optional fullscreen kiosk mode and command interface for embedded applications
Includes omxplayerGUI, an X front end for omxplayer

hippy
Posts: 2169
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Python speed, benchmarks, 2v3

Wed Sep 13, 2017 12:19 pm

paddyg wrote:
Wed Sep 13, 2017 10:58 am
I suppose the message is 'beware of benchmarks' - check the actual app and choose accordingly.
That's very true; which is faster and by how much does seem to depend on exactly what one is doing.

The problem seems to be that no one really knows why or what things are faster or slower so it's impossible to predict which will be best. A greater range of benchmarks might highlight where the improvement and losses lie.

I made my decision to stick with 2.7 because all of my programs run faster with 2.7 than with 3.x and I would presume programs of a similar nature would behave the same and that's what I am most likely to produce.

There also seems to have been a general consensus that people have found 3.x slower than 2.7 but that does not mean it will apply in all cases or forever.

The best course is to code for 2.7 and 3.x compatibility then one can easily switch between the two. That's what I strive for and how I can easily know 2.7 is faster than 3.x. If that ever changes it's near zero effort to make that move.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 17765
Joined: Sat Jul 30, 2011 7:41 pm

Re: Python speed, benchmarks, 2v3

Wed Sep 13, 2017 12:41 pm

hippy wrote:
Wed Sep 13, 2017 12:19 pm
paddyg wrote:
Wed Sep 13, 2017 10:58 am
I suppose the message is 'beware of benchmarks' - check the actual app and choose accordingly.
That's very true; which is faster and by how much does seem to depend on exactly what one is doing.

The problem seems to be that no one really knows why or what things are faster or slower so it's impossible to predict which will be best. A greater range of benchmarks might highlight where the improvement and losses lie.

I made my decision to stick with 2.7 because all of my programs run faster with 2.7 than with 3.x and I would presume programs of a similar nature would behave the same and that's what I am most likely to produce.

There also seems to have been a general consensus that people have found 3.x slower than 2.7 but that does not mean it will apply in all cases or forever.

The best course is to code for 2.7 and 3.x compatibility then one can easily switch between the two. That's what I strive for and how I can easily know 2.7 is faster than 3.x. If that ever changes it's near zero effort to make that move.
Odd that no-one has run the Python interpreters under a profiling tool. That would point out where things are faster/slower. Or maybe the code bases are so dissimilar that comparisons are difficult.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

User avatar
paddyg
Posts: 1917
Joined: Sat Jan 28, 2012 11:57 am

Re: Python speed, benchmarks, 2v3

Wed Sep 13, 2017 1:32 pm

I've profiled quite a bit but it's quite hard to extrapolate. I was mainly trying to just get rid of bottlenecks rather than compare 2 v 3, but I did look at the pypy profile (and concluded that it was essentially incomparable!) You can see, however, that py3 is doing an awful lot more function calls (even if most of them take no time at all)

Code: Select all

Python2.7				
   ncalls	  tottime	  percall	  cumtime	  percall filename:lineno(function)
1	0.245	0.245	0.796	    0.796 pystone.py:79(Proc0)
50000	0.118	0	0.274	    0.000 pystone.py:137(Proc1)
50000	0.078	0	0.096	    0.000 pystone.py:212(Proc8)
50000	0.055	0	0.068	    0.000 pystone.py:233(Func2)
50000	0.042	0	0.063	    0.000 pystone.py:53(copy)
150000	0.036	0	0.036	    0.000 pystone.py:225(Func1)
150000	0.031	0	0.031	    0.000 pystone.py:207(Proc7)
50000	0.031	0	0.041	    0.000 pystone.py:164(Proc3)
50000	0.031	0	0.042	    0.000 pystone.py:188(Proc6)
50000	0.025	0	0.025	    0.000 pystone.py:153(Proc2)
50003	0.02	0	0.02	    0.000 {range}
50002	0.02	0	0.02	    0.000 pystone.py:45(__init__)
100000	0.018	0	0.018	    0.000 {chr}
50000	0.013	0	0.013	    0.000 pystone.py:174(Proc4)
50000	0.012	0	0.012	    0.000 pystone.py:181(Proc5)
50000	0.011	0	0.011	    0.000 pystone.py:250(Func3)
100000	0.009	0	0.009	    0.000 {ord}
51	0	0	0	    0.000 pystone.py:75(<lambda>)
4	0	0	0	    0.000 {time.clock}
1	0	0	0	    0.000 __init__.py:1(<module>)
1	0	0	0	    0.000 pystone.py:33(<module>)
1	0	0	0	    0.000 pystone.py:43(Record)
1	0	0	0.796	    0.796 pystone.py:60(main)
1	0	0	0.796	    0.796 pystone.py:67(pystones)
1	0	0	0.797	    0.797 temp1.py:1(<module>)
1	0	0	0	    0.000 {map}
1	0	0	0	    0.000 {method 'disable' of '_lsprof.Profiler' objects}

Python3.5				
1	0.241	0.241	0.811	    0.811 pystone.py:86(Proc0)
50000	0.134	0	0.309	    0.000 pystone.py:144(Proc1)
50000	0.09	0	0.09	    0.000 pystone.py:219(Proc8)
50000	0.055	0	0.066	    0.000 pystone.py:240(Func2)
50000	0.049	0	0.08	    0.000 pystone.py:60(copy)
50000	0.034	0	0.045	    0.000 pystone.py:171(Proc3)
50000	0.031	0	0.042	    0.000 pystone.py:195(Proc6)
50002	0.031	0	0.031	    0.000 pystone.py:52(__init__)
150000	0.03	0	0.03	    0.000 pystone.py:214(Proc7)
150000	0.029	0	0.029	    0.000 pystone.py:232(Func1)
50000	0.026	0	0.026	    0.000 pystone.py:160(Proc2)
100000	0.018	0	0.018	    0.000 {built-in method builtins.chr}
50000	0.013	0	0.013	    0.000 pystone.py:188(Proc5)
50000	0.011	0	0.011	    0.000 pystone.py:181(Proc4)
50000	0.01	0	0.01	    0.000 pystone.py:257(Func3)
100000	0.009	0	0.009	    0.000 {built-in method builtins.ord}
2	0	0	0	    0.000 <frozen importlib._bootstrap>:119(release)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:159(__init__)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:163(__enter__)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:170(__exit__)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:176(_get_module_lock)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:190(cb)
      3/2	0	0	0.001	    0.000 <frozen importlib._bootstrap>:214(_call_with_frames_removed)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:225(_verbose_message)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:310(__init__)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:314(__enter__)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:321(__exit__)
8	0	0	0	    0.000 <frozen importlib._bootstrap>:324(<genexpr>)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:35(_new_module)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:372(__init__)
4	0	0	0	    0.000 <frozen importlib._bootstrap>:406(cached)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:419(parent)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:427(has_location)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:510(_init_module_attrs)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:570(module_from_spec)
2	0	0	0.001	    0.000 <frozen importlib._bootstrap>:659(_load_unlocked)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:716(find_spec)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:74(__init__)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:789(find_spec)
6	0	0	0	    0.000 <frozen importlib._bootstrap>:852(__enter__)
6	0	0	0	    0.000 <frozen importlib._bootstrap>:856(__exit__)
2	0	0	0.001	    0.000 <frozen importlib._bootstrap>:879(_find_spec)
2	0	0	0.002	    0.001 <frozen importlib._bootstrap>:939(_find_and_load_unlocked)
2	0	0	0	    0.000 <frozen importlib._bootstrap>:94(acquire)
2	0	0	0.002	    0.001 <frozen importlib._bootstrap>:966(_find_and_load)
      2/1	0	0	0.001	    0.001 <frozen importlib._bootstrap>:996(_handle_fromlist)
1	0	0	0	    0.000 <frozen importlib._bootstrap_external>:1047(_path_hooks)
6	0	0	0	    0.000 <frozen importlib._bootstrap_external>:1064(_path_importer_cache)
2	0	0	0.001	    0.000 <frozen importlib._bootstrap_external>:1101(_get_spec)
2	0	0	0.001	    0.000 <frozen importlib._bootstrap_external>:1133(find_spec)
1	0	0	0	    0.000 <frozen importlib._bootstrap_external>:1178(__init__)
8	0	0	0	    0.000 <frozen importlib._bootstrap_external>:1184(<genexpr>)
2	0	0	0	    0.000 <frozen importlib._bootstrap_external>:1210(_get_spec)
5	0	0	0.001	    0.000 <frozen importlib._bootstrap_external>:1215(find_spec)
1	0	0	0	    0.000 <frozen importlib._bootstrap_external>:1260(_fill_cache)
1	0	0	0	    0.000 <frozen importlib._bootstrap_external>:1301(path_hook_for_FileFinder)
4	0	0	0	    0.000 <frozen importlib._bootstrap_external>:246(cache_from_source)
5	0	0	0	    0.000 <frozen importlib._bootstrap_external>:34(_relax_case)
2	0	0	0	    0.000 <frozen importlib._bootstrap_external>:342(_get_cached)
23	0	0	0	    0.000 <frozen importlib._bootstrap_external>:366(_verbose_message)
2	0	0	0	    0.000 <frozen importlib._bootstrap_external>:382(_check_name_wrapper)
2	0	0	0	    0.000 <frozen importlib._bootstrap_external>:419(_validate_bytecode_header)
4	0	0	0	    0.000 <frozen importlib._bootstrap_external>:45(_r_long)
2	0	0	0	    0.000 <frozen importlib._bootstrap_external>:474(_compile_bytecode)
28	0	0	0	    0.000 <frozen importlib._bootstrap_external>:50(_path_join)
2	0	0	0	    0.000 <frozen importlib._bootstrap_external>:513(spec_from_file_location)
28	0	0	0	    0.000 <frozen importlib._bootstrap_external>:52(<listcomp>)
4	0	0	0	    0.000 <frozen importlib._bootstrap_external>:56(_path_split)
2	0	0	0	    0.000 <frozen importlib._bootstrap_external>:656(create_module)
2	0	0	0.001	    0.000 <frozen importlib._bootstrap_external>:659(exec_module)
13	0	0	0	    0.000 <frozen importlib._bootstrap_external>:68(_path_stat)
2	0	0	0	    0.000 <frozen importlib._bootstrap_external>:729(get_code)
6	0	0	0	    0.000 <frozen importlib._bootstrap_external>:78(_path_is_mode_type)
2	0	0	0	    0.000 <frozen importlib._bootstrap_external>:786(__init__)
2	0	0	0	    0.000 <frozen importlib._bootstrap_external>:811(get_filename)
2	0	0	0	    0.000 <frozen importlib._bootstrap_external>:816(get_data)
2	0	0	0	    0.000 <frozen importlib._bootstrap_external>:826(path_stats)
5	0	0	0	    0.000 <frozen importlib._bootstrap_external>:87(_path_isfile)
1	0	0	0	    0.000 <frozen importlib._bootstrap_external>:92(_path_isdir)
1	0	0	0	    0.000 __init__.py:1(<module>)
1	0	0	0	    0.000 pystone.py:40(<module>)
1	0	0	0	    0.000 pystone.py:50(Record)
1	0	0	0.811	    0.811 pystone.py:67(main)
1	0	0	0.811	    0.811 pystone.py:74(pystones)
1	0	0	0	    0.000 pystone.py:82(<listcomp>)
1	0	0	0.812	    0.812 temp1.py:1(<module>)
2	0	0	0	    0.000 {built-in method _imp._fix_co_filename}
6	0	0	0	    0.000 {built-in method _imp.acquire_lock}
1	0	0	0	    0.000 {built-in method _imp.is_builtin}
2	0	0	0	    0.000 {built-in method _imp.is_frozen}
8	0	0	0	    0.000 {built-in method _imp.release_lock}
4	0	0	0	    0.000 {built-in method _thread.allocate_lock}
4	0	0	0	    0.000 {built-in method _thread.get_ident}
1	0	0	0	    0.000 {built-in method builtins.__build_class__}
1	0	0	0.001	    0.001 {built-in method builtins.__import__}
2	0	0	0	    0.000 {built-in method builtins.any}
      3/1	0	0	0.812	    0.812 {built-in method builtins.exec}
12	0	0	0	    0.000 {built-in method builtins.getattr}
12	0	0	0	    0.000 {built-in method builtins.hasattr}
8	0	0	0	    0.000 {built-in method builtins.isinstance}
8	0	0	0	    0.000 {built-in method builtins.len}
2	0	0	0	    0.000 {built-in method builtins.print}
1	0	0	0	    0.000 {built-in method builtins.setattr}
4	0	0	0	    0.000 {built-in method from_bytes}
2	0	0	0	    0.000 {built-in method marshal.loads}
1	0	0	0	    0.000 {built-in method posix.getcwd}
1	0	0	0	    0.000 {built-in method posix.listdir}
13	0	0	0	    0.000 {built-in method posix.stat}
4	0	0	0	    0.000 {built-in method time.time}
1	0	0	0	    0.000 {method 'disable' of '_lsprof.Profiler' objects}
2	0	0	0	    0.000 {method 'endswith' of 'str' objects}
3	0	0	0	    0.000 {method 'extend' of 'list' objects}
20	0	0	0	    0.000 {method 'format' of 'str' objects}
32	0	0	0	    0.000 {method 'join' of 'str' objects}
2	0	0	0	    0.000 {method 'read' of '_io.FileIO' objects}
17	0	0	0	    0.000 {method 'rpartition' of 'str' objects}
60	0	0	0	    0.000 {method 'rstrip' of 'str' objects}
2	0	0	0	    0.000 {method 'startswith' of 'str' objects}
for completeness pypy
   ncalls	  tottime	  percall	  cumtime	  percall filename:lineno(function)
1	0.189	0.189	0.412	    0.412 pystone.py:79(Proc0)
50000	0.081	0	0.083	    0.000 pystone.py:212(Proc8)
1	0.074	0.074	0.487	    0.487 temp1.py:1(<module>)
150000	0.031	0	0.031	    0.000 pystone.py:225(Func1)
50000	0.024	0	0.027	    0.000 pystone.py:233(Func2)
50002	0.023	0	0.023	    0.000 pystone.py:45(__init__)
50000	0.019	0	0.062	    0.000 pystone.py:137(Proc1)
100000	0.009	0	0.009	    0.000 {ord}
50000	0.007	0	0.03	    0.000 pystone.py:53(copy)
150000	0.006	0	0.006	    0.000 pystone.py:207(Proc7)
50000	0.004	0	0.006	    0.000 pystone.py:164(Proc3)
50000	0.004	0	0.006	    0.000 pystone.py:188(Proc6)
50000	0.003	0	0.003	    0.000 pystone.py:153(Proc2)
50000	0.002	0	0.002	    0.000 pystone.py:174(Proc4)
50000	0.002	0	0.002	    0.000 pystone.py:181(Proc5)
50000	0.002	0	0.002	    0.000 pystone.py:250(Func3)
100000	0.002	0	0.002	    0.000 {chr}
50003	0.002	0	0.002	    0.000 {range}
1	0.001	0.001	0.001	    0.001 pystone.py:3(<module>)
1	0	0	0	    0.000 __init__.py:1(<module>)
2	0	0	0	    0.000 _structseq.py:22(__get__)
1	0	0	0	    0.000 pystone.py:43(Record)
1	0	0	0.412	    0.412 pystone.py:60(main)
1	0	0	0.412	    0.412 pystone.py:67(pystones)
51	0	0	0	    0.000 pystone.py:75(<lambda>)
1	0	0	0	    0.000 {method 'disable' of '_lsprof.Profiler' objects}
4	0	0	0	    0.000 {time.clock}

also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d

bensimmo
Posts: 1694
Joined: Sun Dec 28, 2014 3:02 pm
Location: East Yorkshire

Re: Python speed, benchmarks, 2v3

Wed Sep 13, 2017 2:53 pm

While looking at 3.6 optimisations and whatnot ( and not knowing what most is used for).
I do remember reading (month back or so) they have people in place to go through optimising code, especially as python is bloating as more and more things are added. It was some article to with the ever expanding code and size of Python.

But perhaps from a simple point of view, you loose speed by making it more flexible and feature rich, debugging rich and/or a move to optimise for memory Vs speed.
Or even, there are now better and faster ways to write it in code and people are stuck in fuddy duddy python2 style.
(Just as a side, plenty of Stretch has been made Python 3 compatible reading the docs, compared to Jessie, and that Debian of all things ;-))

Who knows, not me. But it's interesting reading.

hippy
Posts: 2169
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Python speed, benchmarks, 2v3

Wed Sep 13, 2017 5:33 pm

bensimmo wrote:
Wed Sep 13, 2017 2:53 pm
But perhaps from a simple point of view, you loose speed by making it more flexible and feature rich, debugging rich and/or a move to optimise for memory Vs speed.
I think that is mostly it. Some 'improvement' or change somewhere adds an instruction or two. Data structures change, access code consequently alters, bugs get fixed, things get added and that means more instructions to execute. I do think that is all we are seeing; a consequence of the Python interpreter evolving.

I don't think 3.x is flawed; it's just the way it is. As newer versions arrive they do seem to be delivering faster execution so it seems there is some optimisation going on. I guess there is scope for more but that can always be a challenge, at odds with simplicity, elegance, readability, maintainability or something else.

billintad
Posts: 33
Joined: Tue Jul 28, 2015 10:21 pm

Re: Python speed, benchmarks, 2v3

Thu Sep 14, 2017 9:39 am

See the Python Speed centre for a comparison using a variety of benchmarks : https://speed.python.org/comparison/

These benchmarks are for CPython only.

hippy
Posts: 2169
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Python speed, benchmarks, 2v3

Thu Sep 14, 2017 10:19 am

Those speed tests are interesting. The takeaway from that for me would be that 3.6 is generally faster than 2.7, few cases where there would be an advantage to using 2.7.

But that is at odds with the real world experiences of many, which seems to take us back to "beware of benchmarks", that benchmarks and speed tests are not always as indicative of real world performance as one might like.

It does however seem quite strange that real world performance is often so at odds with what might be predicted. Why that is remains a mystery.

I think that's the real problem. If someone said, 'yes, integers are slower, strings are slower', 'you're doing it wrong for 3.x', I would know why, would accept that, could take steps to improve things. As it is I can only say, for me, 3.x is much slower than 2.7, and I have no idea why that is.

billintad
Posts: 33
Joined: Tue Jul 28, 2015 10:21 pm

Re: Python speed, benchmarks, 2v3

Fri Sep 15, 2017 3:23 pm

hippy wrote:
Thu Sep 14, 2017 10:19 am
....
I think that's the real problem. If someone said, 'yes, integers are slower, strings are slower', 'you're doing it wrong for 3.x', I would know why, would accept that, could take steps to improve things. As it is I can only say, for me, 3.x is much slower than 2.7, and I have no idea why that is.
I believe 3.6 is slower because integers are type "long" rather than "int", string processing can be slower because strings are Unicode strings and start-up is slower. For applications it is likely that the performance could be improved with a change to a programming style which exploits the those features of 3.6 which are much quicker, for example, improvements for dictionaries.

It is a shame that Python 3.6 is not available via apt-get as this version, as well as 3.7 when it comes along, will have performance improvements.

wally333
Posts: 32
Joined: Mon Jun 06, 2016 7:09 pm

Re: Python speed, benchmarks, 2v3

Sat Sep 16, 2017 12:55 am

To me its simple, if all the libraries and modules you need are available in python3 use it as its the future -- like it or not.

If not, better to use python 2 that get stuck trying to re-invent the wheel for a library that has not yet been ported.

Return to “Python”

Who is online

Users browsing this forum: No registered users and 15 guests