101

I've always thought that Python's advantages are code readibility and development speed, but time and memory usage were not as good as those of C++.

These stats struck me really hard.

What does your experience tell you about Python vs C++ time and memory usage?

igouy
  • 2,547
  • 17
  • 16
Alex
  • 43,191
  • 44
  • 96
  • 127
  • 21
    So Pyhton is for most of these cases slower and uses more RAM but the source is smaller. What exactly is the problem? – nuriaion Apr 29 '09 at 09:54
  • 2
    I guess I misinterpreted the results. – Alex Apr 29 '09 at 10:36
  • 6
    What's really interesting is that the C++ tests are still 'better' than the C ones! – gbjbaanb Apr 29 '09 at 10:38
  • Interesting, they made results a bit less intuitive. Btw python pidigits result is impressive (modules are the great thing). – Alex Bolotov Apr 29 '09 at 13:34
  • 9
    @gbjbaanb: Doesn't surprise me. C++ has added a lot of feature that enable potentially faster code. If you know what you're doing, C++ can be ridiculously efficient, more so than C. (Of course, C++ also includes some features that hurt performance, but you don't have to use them). But the common belief that "C is faster than C++" is wrong. (and the question isn't very meaningful in the first place) – jalf Apr 29 '09 at 15:15
  • @Bolotov "Interesting, they made results a bit less intuitive." - People misinterpreted the previous presentation of results, that's why it changed. Now larger means larger - more time, more memory, more source code. – igouy Apr 30 '09 at 17:12
  • @igouy It still appears rather easy to misinterpret if you don't read the title and the values on the y-axis. Can definitely be further improved. :) – moinudin May 01 '09 at 09:11
  • @marcog If that's so definite then why haven't you made any suggestion? :-) – igouy May 02 '09 at 00:09
  • 2
    The link is dead – Arn Feb 04 '20 at 23:36
  • Python is not a bad language indeed and has the valuable use cases, but I still think a question like that should just be deleted. – Audrius Meškauskas Aug 23 '20 at 10:03
  • 1
    Look at this: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gpp-python3.html IMHO: That is much worse than what you could ever hope for :D – Sold Out Feb 18 '21 at 11:35

8 Answers8

273

I think you're reading those stats incorrectly. They show that Python is up to about 400 times slower than C++ and with the exception of a single case, Python is more of a memory hog. When it comes to source size though, Python wins flat out.

My experiences with Python show the same definite trend that Python is on the order of between 10 and 100 times slower than C++ when doing any serious number crunching. There are many reasons for this, the major ones being: a) Python is interpreted, while C++ is compiled; b) Python has no primitives, everything including the builtin types (int, float, etc.) are objects; c) a Python list can hold objects of different type, so each entry has to store additional data about its type. These all severely hinder both runtime and memory consumption.

This is no reason to ignore Python though. A lot of software doesn't require much time or memory even with the 100 time slowness factor. Development cost is where Python wins with the simple and concise style. This improvement on development cost often outweighs the cost of additional cpu and memory resources. When it doesn't, however, then C++ wins.

greeness
  • 15,956
  • 5
  • 50
  • 80
moinudin
  • 134,091
  • 45
  • 190
  • 216
  • 133
    Also, people who speak of Python being slow for serious number crunching haven't used the Numpy and Scipy modules. Python is really taking off in scientific computing these days. Of course, the speed comes from using modules written in C or libraries written in Fortran, but that's the beauty of a scripting language in my opinion. – Justin Peel Nov 22 '10 at 22:42
  • 4
    I asure what you said and this a link to prove it : http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/ – ucefkh Dec 25 '12 at 02:29
  • 3
    Regarding: *c) a Python list can hold objects of different type, so each entry has to store additional data about its type.* The python list is really a list of pointers to objects. In python it's the value that knows it's type, while the variable is only a pointer to the "generic value object" (therefore even numbers are immutable). So lists are not storing the types of it's contents - just pointers. You are right about the memory overhead though - python does have to store the type and other context for values of any type. – Alex May 22 '13 at 09:13
  • 1
    if you talk about cpython..then yes, but pypy is in most cases very fast (comparable with java, 1/3 speed of java i guess), subsets of python are ever nearly as fast as c++ (see shedskin) – Quonux Apr 19 '14 at 17:46
  • 2
    @JustinPeel i question whether that's true. even when making extensive use of `numpy` and `scipy`, a large `python` code base is likely to have a lot of code in pure python, making things slower than `C++`. a python script approaches the speed of a `C++` script as the percentage of its `C` code goes to `100`, at which point it is no longer a python script. python is taking off, for sure, but not because it is as fast as `C++` -- because it is easier to use. – abcd Oct 15 '15 at 04:03
  • @dbliss Yes, there are many factors to consider. Yes, it is the C, C++, Cython and Fortran code underneath numpy, scipy and other libraries that really speed things up. How fast Python code is definitely depends on which parts are most computationally intensive. However, you can also speed up various parts of your code using Cython or other means if necessary. When I use C++, I also leverage code that other people have written. I don't make my own std::vector every time I want a data structure like that. CPython is written in C too so all of my Python code is really C when run with CPython. – Justin Peel Nov 05 '15 at 07:08
  • 1
    It's funny that people complain about a language instead of their own programming skills – Confuse Nov 11 '16 at 08:34
  • Now a days, latest report shows that the Execution time of Python, C++ and Go is almost gets equal. Take complete detail here: https://www.auedbaki.com/article/pythons-execution-time-is-close-to-c-and-go-language-study-1579629041593 – Yashdeep Raj Jan 21 '20 at 17:53
  • 1
    @auedbaki: "Python also comes closer once compiled using the Numba compiler." Then it is not Python though. Numba can handle only a subset of Python and Numpy. That comparison doesn't apply to arbitrary Python programs. – Cris Luengo Mar 12 '21 at 22:42
143

All the slowest (>100x) usages of Python on the shootout are scientific operations that require high GFlop/s count. You should NOT use python for those anyways. The correct way to use python is to import a module that does those calculations, and then go have a relaxing afternoon with your family. That is the pythonic way :)

Tim Lin
  • 3,244
  • 2
  • 19
  • 17
  • 4
    Nowadays there are several [Python-to-C++ compilers](https://stackoverflow.com/questions/4650243/convert-python-program-to-c-c-code), so Python can be as fast as C++ in some cases. – Anderson Green Aug 02 '17 at 01:37
26

My experience is the same as the benchmarks. Python can be slow and uses more memory. I write much, much less code and it works the first time with much less debugging. Since it manages memory for me, I don't have to do any memory management, saving hours of chasing down core leaks.

What's your question?

S.Lott
  • 384,516
  • 81
  • 508
  • 779
  • I just was confused by the results of the benchmarks. Turns out I misinterpreted them. – Alex Apr 29 '09 at 10:35
15

Source size is not really a sensible thing to measure. For example, the following shell script:

cat foobar

is much shorter than either its Python or C++ equivalents.

  • 40
    And much easier to maintain that the longer Python or C++ versions, too. I argue the source code size does matter, and for certain simple tasks, terse shell scripts are good. – S.Lott Apr 29 '09 at 10:23
  • I also believe that source code size matters a lot, and for some tasks, Bash is the right tool for the job. See a nice example comparing a simple bash script to python here: http://innolitics.com/articles/programming-languages/#what-makes-programming-languages-different (you need to scroll down a bit). I think it is a slightly more sophisticated example than `cat footer`. – jdg Feb 02 '18 at 23:00
  • This thread is about code speed/size, not maintainability. – Noob Sep 13 '21 at 09:28
8

Also: Psyco vs. C++.

It's still a bad comparison, since noone would do the numbercrunchy stuff benchmarks tend to focus on in pure Python anyway. A better one would be comparing the performance of realistic applications, or C++ versus NumPy, to get an idea whether your program will be noticeably slower.

millimoose
  • 39,073
  • 9
  • 82
  • 134
  • 2
    in other words - since numbercrunchy stuff is so much slower write it in C++ and call it from Python :-) – igouy Apr 30 '09 at 17:20
  • 1
    If your going to use a library in python to make it faster, then you might as well use a number crunching library in c++. That way you keep the flexibility of c++ without having to write a bunch of code :) – SuperSim135 May 15 '20 at 20:02
  • 1
    That’s a *god-tier* pointless necro. OP literally states preferring Python for readability and convenience, why would somebody directly use a language they like less, when they can get most of the performance benefits by having library authors take care of those for him? The point of using libraries is not having to do the sort of work they do better yourself, that a library happens to be a native binding is an optimization/implement detail. – millimoose May 30 '20 at 09:33
6

The problem here is that you have two different languages that solve two different problems... its like comparing C++ with assembler.

Python is for rapid application development and for when performance is a minimal concern.

C++ is not for rapid application development and inherits a legacy of speed from C - for low level programming.

jheriko
  • 3,043
  • 1
  • 21
  • 28
4

It's the same problem with managed and easy to use programming language as always - they are slow (and sometimes memory-eating).

These are languages to do control rather than processing. If I would have to write application to transform images and had to use Python too all the processing could be written in C++ and connected to Python via bindings while interface and process control would be definetely Python.

Migol
  • 8,161
  • 8
  • 47
  • 69
  • Those libraries are already written for Python or C or Java, so why not use a dynamic language to glue them together? – aoeu256 Jul 11 '19 at 16:13
2

I think those stats show that Python is much slower and uses more memory for those benchmarks - are you sure you're reading them the right way up?

In my experience, which is mostly with writing network- and file-system-bound programs in Python, Python isn't significantly slower in any way that matters. For that kind of work, its benefits outweigh its costs.

RichieHindle
  • 272,464
  • 47
  • 358
  • 399
  • Indeed. WHen performance is an issue, what python is good at is binding together high performance external modules, or prototyping the system and then allowing the bottlenecks (usually deep in an inner loop) to be rewritten as a C module etc. – xan Apr 29 '09 at 11:20