76

Why does Python seem slower, on average, than C/C++? I learned Python as my first programming language, but I've only just started with C and already I feel I can see a clear difference.

John Saunders
  • 157,405
  • 24
  • 229
  • 388
Riemannliness
  • 951
  • 1
  • 7
  • 9
  • 15
    Are you aware that Python is interpreted? – S.Lott Jun 13 '10 at 19:38
  • 9
    @kaizer.se - then we also need to say the other obvious truths, we don't work with programming languages we work with programming language implementations; etc etc – igouy Jun 15 '10 at 15:07
  • 6
    @kaizer.se: yes, we know, we know. But just think how awkward it is to write while avoiding comments like yours. "Why is Python code (run with any common interpreter) so slow?" – Cascabel Jun 15 '10 at 16:16
  • 6
    After [much discussion](http://meta.stackexchange.com/questions/54215/why-is-python-so-slow-shouldnt-have-been-closed-and-deleted), this question has been given a second chance. I've edited the tone to prevent its (re-)closure and (re-)deletion. It amazes me that none of the 1000 viewers of this question, many of whom voted up the question or answers, saw fit to dispute the closure reason or act to fix the argumentative tone of the question. – ire_and_curses Jun 19 '10 at 06:16

10 Answers10

93

Python is a higher level language than C, which means it abstracts the details of the computer from you - memory management, pointers, etc, and allows you to write programs in a way which is closer to how humans think.

It is true that C code usually runs 10 to 100 times faster than Python code if you measure only the execution time. However if you also include the development time Python often beats C. For many projects the development time is far more critical than the run time performance. Longer development time converts directly into extra costs, fewer features and slower time to market.

Internally the reason that Python code executes more slowly is because code is interpreted at runtime instead of being compiled to native code at compile time.

Other interpreted languages such as Java bytecode and .NET bytecode run faster than Python because the standard distributions include a JIT compiler that compiles bytecode to native code at runtime. The reason why CPython doesn't have a JIT compiler already is because the dynamic nature of Python makes it difficult to write one. There is work in progress to write a faster Python runtime so you should expect the performance gap to be reduced in the future, but it will probably be a while before the standard Python distribution includes a powerful JIT compiler.

Mark Byers
  • 719,658
  • 164
  • 1,497
  • 1,412
  • 44
    To be pedantic: Python is not typically compiled to *native* code at compile time. Python bytecode still must be interpreted. – Mark Byers Jun 13 '10 at 19:24
  • 20
    You haven't really explained why Python implementations tend to be so CPU-hungry. You can abstract all of the above without incurring all that much cost at runtime; it's the extremely dynamic nature of Python that eats all the CPU: all of those attribute lookups/method dispatches add up, and give even JITs a fairly hard time -- and Python is usually used without a JIT at the moment. – SamB Jun 13 '10 at 20:28
  • @SamB: I've now added a comparison to other interpeted languages to address your point. The part I wrote about abstactions was not to explain why Python is slower to run, but to explain why it can be faster to program. – Mark Byers Jun 13 '10 at 21:06
  • 2
    In retrospect, I think it's worth noting the global interpreter lock and the way all objects in Python are heap allocated objects, even a simple integer. Without getting into specific implementation details, these types of things, aside from the higher level abstractions, can weigh in quite heavily on performance. That said, I still think most applications should be written primarily in a scripting language like Python. As Knuth states about premature optimization, only small parts of most applications are actually very performance-critical. – stinky472 Feb 01 '12 at 16:15
  • +1 [Honestly speaking this is why i am learning python, to speed my production software, where boss demands speed in development] - "It is true that C code usually runs 10 to 100 times faster than Python code if you measure only the execution time. However if you also include the development time Python often beats C. For many projects the development time is far more critical than the run time performance. Longer development time converts directly into extra costs, fewer features and slower time to market." –  Jun 03 '12 at 10:00
  • C,Java are way faster than python – Saurabh Dec 24 '15 at 12:26
  • This could be related, but if the interpretation was that slow than Node.js would not be much faster, if faster at all, than python. – Triforcey Apr 11 '17 at 17:13
  • "Premature optimization." Yeah no. That quote refers to "small efficiency improvements", not 100x factors. There is absolutely no excuse for CPython's slow speed considering how central it is in many situations. Common lisp existed before Python, was far more expressive, and a good implementation will run within a factor 3 of C. Modern scripting languages built with a JIT in mind like Julia get speeds comparable to C, without giving up any expressiveness. – saolof Nov 07 '17 at 07:04
50

CPython is particularly slow because it has no Just in Time optimizer (since it's the reference implementation and chooses simplicity over performance in certain cases). Unladen Swallow is a project to add an LLVM-backed JIT into CPython, and achieves massive speedups. It's possible that Jython and IronPython are much faster than CPython as well as they are backed by heavily optimized virtual machines (JVM and .NET CLR).

One thing that will arguably leave Python slower however, is that it's dynamically typed, and there is tons of lookup for each attribute access.

For instance calling f on an object A will cause possible lookups in __dict__, calls to __getattr__, etc, then finally call __call__ on the callable object f.

With respect to dynamic typing, there are many optimizations that can be done if you know what type of data you are dealing with. For example in Java or C, if you have a straight array of integers you want to sum, the final assembly code can be as simple as fetching the value at the index i, adding it to the accumulator, and then incrementing i.

In Python, this is very hard to make code this optimal. Say you have a list subclass object containing ints. Before even adding any, Python must call list.__getitem__(i), then add that to the "accumulator" by calling accumulator.__add__(n), then repeat. Tons of alternative lookups can happen here because another thread may have altered for example the __getitem__ method, the dict of the list instance, or the dict of the class, between calls to add or getitem. Even finding the accumulator and list (and any variable you're using) in the local namespace causes a dict lookup. This same overhead applies when using any user defined object, although for some built-in types, it's somewhat mitigated.

It's also worth noting, that the primitive types such as bigint (int in Python 3, long in Python 2.x), list, set, dict, etc, etc, are what people use a lot in Python. There are tons of built in operations on these objects that are already optimized enough. For example, for the example above, you'd just call sum(list) instead of using an accumulator and index. Sticking to these, and a bit of number crunching with int/float/complex, you will generally not have speed issues, and if you do, there is probably a small time critical unit (a SHA2 digest function, for example) that you can simply move out to C (or Java code, in Jython). The fact is, that when you code C or C++, you are going to waste lots of time doing things that you can do in a few seconds/lines of Python code. I'd say the tradeoff is always worth it except for cases where you are doing something like embedded or real time programming and can't afford it.

  • Doesn't Unladen Swallow currently use slightly more memory? 2009 Q2 [http://code.google.com/p/unladen-swallow/wiki/Release2009Q2] results say memory increased by 10x, and 2009 Q3 [http://code.google.com/p/unladen-swallow/wiki/Release2009Q3] says they got it down by 930% (not sure how to interpret that number). It sounds like lower memory is a goal, but not achieved yet. – Brendan Long Jun 13 '10 at 21:06
  • doh, that sentence I wrote didn't even make sense anyways. – L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ Jun 13 '10 at 21:12
  • "One thing that will arguably leave Python slower however, is that it's dynamically typed, and there is tons of lookup for each attribute access." Actually this is where the JIT in PyPy really wins. The JIT can notice that your code is doing something non-tricky and simple, and can optimize to some simple machine instructions. Thus PyPy is now much faster than CPython anytime you do something simple in a loop. – steveha Oct 04 '13 at 02:04
20

Compilation vs interpretation isn't important here: Python is compiled, and it's a tiny part of the runtime cost for any non-trivial program.

The primary costs are: the lack of an integer type which corresponds to native integers (making all integer operations vastly more expensive), the lack of static typing (which makes resolution of methods more difficult, and means that the types of values must be checked at runtime), and the lack of unboxed values (which reduce memory usage, and can avoid a level of indirection).

Not that any of these things aren't possible or can't be made more efficient in Python, but the choice has been made to favor programmer convenience and flexibility, and language cleanness over runtime speed. Some of these costs may be overcome by clever JIT compilation, but the benefits Python provides will always come at some cost.

  • 1
    Better answer than the accepted one, although it's important to note that python is not always compiled. It is really the implementation. It is interpreted more often than not in my experience. – Triforcey Apr 11 '17 at 17:19
8

The difference between python and C is the usual difference between an interpreted (bytecode) and compiled (to native) language. Personally, I don't really see python as slow, it manages just fine. If you try to use it outside of its realm, of course, it will be slower. But for that, you can write C extensions for python, which puts time-critical algorithms in native code, making it way faster.

Femaref
  • 58,195
  • 7
  • 126
  • 170
  • 2
    s/it's/its. Interpreted vs compiled means **nothing** in terms of optimizability. JVM and C can be either interpreted or compiled. Different optimizations can be applied in either case (adaptive optimization vs compile time + LTO) – L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ Jun 13 '10 at 18:26
  • 4
    python compiles to bytecode, which then is interpreted. it can also be compiled to machine code, so in essence, neither of us is right. – Femaref Jun 13 '10 at 19:29
  • 2
    In addition to being not-exactly-true, this answer doesn't talk about the real problem, which @Longpoke explains reasonably well in his answer. – SamB Jun 13 '10 at 20:15
4

Other than the answers already posted, one thing is pythons ability to change things in runtime that you can't change in for example C. You can add member functions to classes as you go. Also, pythons dynamic nature makes it impossible to say what type of parameters will be passed to a function, which in turn makes optimizing a whole lot harder.

RPython seems to be a way of getting around the optimization problem.

Still, it'll probably won't be near the performance of C for numbercrunching and the like.

Mattias Nilsson
  • 3,426
  • 1
  • 20
  • 27
4

Comparing C/C++ to Python is not a fair comparison. Like comparing a F1 race car with a utility truck.

What is surprising is how fast Python is in comparison to its peers of other dynamic languages. While the methodology is often considered flawed, look at The Computer Language Benchmark Game to see relative language speed on similar algorithms.

The comparison to Perl, Ruby, and C# are more 'fair'

dawg
  • 80,841
  • 17
  • 117
  • 187
  • 3
    I prefer to use the metaphor of a Lamborghini speeding to work 5 blocks away (non memory-safe languages) vs a street car obeying speed limits (memory-safe languages). :) – L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ Jun 13 '10 at 19:00
  • C# is statically typed btw, although it has optional dynamic types. – L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ Jun 13 '10 at 20:02
  • 5
    C seems more like a rocket car to me -- great if you want to go in a straight line and there isn't anything to crash into nearby, otherwise not so much! – SamB Jun 13 '10 at 20:17
  • @drewk - you don't seem to have even read the title correctly for that website. – igouy Jun 15 '10 at 15:11
  • @drewk - "often considered flawed" show some evidence for that innuendo. – igouy Jun 15 '10 at 15:12
  • @igouy The name "The Great Computer Language Shootout" was the name prior to Debian's sponsorship. You can still find it with Google with that name and others with a similar name like http://dada.perl.it/shootout/index.html – dawg Jun 15 '10 at 16:00
  • @igouy `often considered flawed` The site itself: http://shootout.alioth.debian.org/flawed-benchmarks.php. Each benchmark is only as good as the person who wrote it, because they are not all the same algorithm. A successful result is solely based on the output, and the language specific optimizations are only as good as the author in that language. You might have highly optimized C being compared to slapped together Perl. Not only is the language slower, the algorithm may be slower. That is interesting comparison, but flawed. – dawg Jun 15 '10 at 16:06
  • @drewk - "was the name prior to Debian's sponsorship" - Debian don't sponsor it. If you really want us to look at a website that hasn't been updated since 2001 then link to the wayback machine, otherwise please have the courtesy to use the name chosen for the website you have do link to. – igouy Jun 15 '10 at 22:18
  • @drewk - The remarks you list don't come from "The site itself". The generalities you list apply to EVERY comparison between languages based on comparing programs. (And we can see from the "interesting alternatives" that it's untrue to say "a successful result is solely based on the output"). – igouy Jun 15 '10 at 22:26
  • @igouy: What do you mean "hasn't been updated since 2001?" Some of the languages in the benchmark did not even exist in 2001 (C#, F#) the Intel quad core reference machine did not exist in 2001. This site is regularly updated. Help me out here: What is your issue? I am not making any sweeping condemnation of the methodology. It is interesting, useful, but flawed in some ways. What is your issue with that? Look at the Mandlebrot benchmark in Pascal, C, Perl and Python. The C program is highly optimized for 4 cores; Perl and Pascal have no optimizations at all. Big surprise: C is faster – dawg Jun 18 '10 at 14:43
  • @drewk >> The C program is highly optimized for 4 cores; Perl and Pascal have no optimizations at all.<< Not true, check the "≈ CPU Load". These Perl and Pascal mandelbrot programs are written to use 4 cores - http://shootout.alioth.debian.org/u32q/program.php?test=mandelbrot&lang=fpascal&id=2 http://shootout.alioth.debian.org/u32q/program.php?test=mandelbrot&lang=perl&id=1 – igouy Jun 20 '10 at 16:57
  • @drewk >> What is your issue? << My issue is you keep writing stuff that isn't correct. – igouy Jun 20 '10 at 16:59
  • @igouy: You are right: The Perl code there was updated May 2010 to multithreaded. But wait! You claimed `the website that hasn't been updated since 2001` but you point me to a page dated May, 2010. Some Perl authors must have successfully produced the required output faster than the last Perl version. O but whoops! You claim it is not based on output! What is it based on then other than the diff to the reference output that they have? Please, if you have >> constructive << comments on the post I did or the OP to increase the accuracy, please let me know. – dawg Jun 22 '10 at 08:00
  • @drewk The website that is active and frequently updated is "The Computer Language Benchmarks Game". – igouy Jun 24 '10 at 00:45
  • @drewk - Again, you were wrong to say "a successful result is solely based on the output" and here's an example that demonstrates you were wrong to say that - this program produces the required output but isn't included, it's shown as an "interesting alternative" - http://shootout.alioth.debian.org/u32/program.php?test=threadring&lang=java&id=6 – igouy Jun 24 '10 at 00:53
  • @drewk >> The Perl code there was updated May 2010 to multithreaded << No, it was last timed in May 2010, that multithreaded Perl mandelbrot was first timed in March 2009. – igouy Jun 24 '10 at 01:00
  • @igouy I did say "a successful result is solely based on the output" and stand behind that. You also correctly state >> this program produces the required output __but isn't included__ << in the benchmark result. If the interesting alternatives with a different time were included in the result, it would throw off the benchmark totals, correct? So what is a "successful result?" Being listed on the website or being listed and included in the language benchmark result? I use the later as "success" not the former. – dawg Jun 24 '10 at 09:55
  • @igouy After all that drama, I think your __constructive comment__ is that I put the wrong web site title --- happy to make that edit. – dawg Jun 24 '10 at 09:59
  • @drewk - after 9 days of quarrelling since I mentioned it, thank you for putting the correct web site title in your post ;-) – igouy Jun 24 '10 at 17:03
  • @drewk >> I use the later as "success" [being listed and included in the language benchmark result] << And because you sensibly think "success" means being included in the benchmark result, you are demonstrably wrong to say "a successful result is solely based on the output". If it was "solely based on the output" there would be no reason not to include that program in the benchmark result. [Do you realise I'm the guy who decides which programs to include and exclude?] – igouy Jun 24 '10 at 17:10
  • @igouy We are in screaming agreement: "success" is being listed __and__ being included in the benchmark. You brought up the "interesting alternatives" as potentially a "success" which I do not agree with. – dawg Jun 25 '10 at 15:56
  • @igouy There can only be one listing included in the benchmark result from each language class, correct? Only the fastest from each submission from each is included, correct? The listing is included only if correctly produces the output, correct? When I say "a successful result is based solely on output" I cannot see why that is at odds with a) producing the required output, b) being including in the benchmark if it is the fastest submitted. I cannot see how the "interesting alternative" would be anything other than something that does produce the required output but not the fastest. – dawg Jun 25 '10 at 15:59
  • @igouy `after 9 days of quarrelling since I mentioned it, thank you for putting the correct web site title in your post` Well the tone of your original comments certainly masked the content and could have been written in a more constructive way. If you are involved in that site, I do respect it. Also, I certainly did not mean to offend you in any way and apologize if I did. Other than the site title, I still think that my post is correct: The submission in each language is only as good as its author and the algorithm used. This is interesting, but not objectively true comparison of raw speed. – dawg Jun 25 '10 at 16:17
  • @drewk >> I cannot see how the "interesting alternative" would be anything other than something that does produce the required output but not the fastest << I pointed you to an example "thread-ring Java #6". That program produces the correct output. That program is 60% faster than the fastest included program. That program uses 1 thread BUT the benchmark says "create 503 linked threads". – igouy Jun 26 '10 at 16:12
  • @drewk >> The submission in each language is only as good as its author and the algorithm used. << Please point to some comparison between languages based on comparing programs where that isn't true. – igouy Jun 26 '10 at 16:16
  • @igouy >>Please point to some comparison between languages based on comparing programs where that isn't true<<   To paraphrase what Churchhill said about Democracy: it is the worst possible testing method except  for all the alternative. ;-)  I used to be involved in video card benchmarking, and first we had very specific benchmarks were fair comparisons -- until manufactures literally designed hardware and drivers to execute the benchmark well at the expense of overall performance. Humans like simple answers: this is faster than that. Some things escape attempts for objective simple answers. – dawg Jul 02 '10 at 09:15
  • @drewk >> Some things escape attempts for objective simple answers << "Some things" might - but the question is C and Python performance. Rather than constructive, I'd characterise your comment as vague and dismissive. – igouy Jul 02 '10 at 17:06
  • @igouy Sorry you took my comments as >> vague and dismissive << I certainly did not mean them that way at all. Certainly not dismissive and it is hard to be precise in 600 characters. Once again -- really -- I am not trying to offend you, be dismissive, etc. All I was pointing out is that each language's performance in the benchmark is only as good as the author. I cannot see the controversy in that. – dawg Jul 02 '10 at 17:30
  • @drewk >> only as good as the author << If you commented on specific inefficiencies in specific programs written by the same person, then that might be an appropriate summing-up. As it is, your comment is empty - it doesn't help us understand if the authors were not so good or whether the authors were uniformly outstanding and provided superb programs. Your comment leaves the vague impression the programs are not as good as they could be, without in any way showing that to be true - vague and dismissive. I'm not offended, I'm disappointed. – igouy Jul 03 '10 at 16:30
  • To disallow comparing between languages to get the faster one is like burning books. Any comparison is a fair one. If I want to learn a fast language, I'm going to compare languages for speed. Any comparison is fair in any context. – Triforcey Apr 11 '17 at 17:23
4

Python is typically implemented as a scripting language. That means it goes through an interpreter which means it translates code on the fly to the machine language rather than having the executable all in machine language from the beginning. As a result, it has to pay the cost of translating code in addition to executing it. This is true even of CPython even though it compiles to bytecode which is closer to the machine language and therefore can be translated faster. With Python also comes some very useful runtime features like dynamic typing, but such things typically cannot be implemented even on the most efficient implementations without heavy runtime costs.

If you are doing very processor-intensive work like writing shaders, it's not uncommon for Python to be somewhere around 200 times slower than C++. If you use CPython, that time can be cut in half but it's still nowhere near as fast. With all those runtmie goodies comes a price. There are plenty of benchmarks to show this and here's a particularly good one. As admitted on the front page, the benchmarks are flawed. They are all submitted by users trying their best to write efficient code in the language of their choice, but it gives you a good general idea.

I recommend you try mixing the two together if you are concerned about efficiency: then you can get the best of both worlds. I'm primarily a C++ programmer but I think a lot of people tend to code too much of the mundane, high-level code in C++ when it's just a nuisance to do so (compile times as just one example). Mixing a scripting language with an efficient language like C/C++ which is closer to the metal is really the way to go to balance programmer efficiency (productivity) with processing efficiency.

stinky472
  • 6,459
  • 25
  • 27
  • By your definition, Java is a scripting language too? Both languages have some sort of byte-code that is executed in a virtual machine. Only difference is, python compiles on-the-fly when needed, which Java normally doesn't do. – Mattias Nilsson Jun 26 '10 at 19:59
  • @Mattias: No; while you are correct that both use bytecode, Java compiles bytecode into native machine language (either in advance or with a JIT compiler) prior to execution. In some cases, Java bytecode is the native machine language of certain microprocessors. CPython, on the other hand, is a strict bytecode *interpreter*. It does all that translation work on the fly, which is why it is often about twice as fast as other Python implementations but still not nearly as fast as Java. – stinky472 Jun 27 '10 at 00:11
  • 1
    Also CPython does not compile-on-the-fly so much as interpret bytecode on the fly. Typical implementations are going to re-translate the same bytecode over and over, like if you have a loop. That's why it's still considered a bytecode interpreter rather than a compiler. CPython does *compile* .py files to .pyc on the fly (Python to bytecode), but that's a totally different thing. pyc is just code that's easier for the interpreter to read and translate, but it's still interpreted. The Java approach is more of a hybrid and it's not just because of the bytecode, but what it does with it. – stinky472 Jun 27 '10 at 00:18
  • Okay, we're getting into questions of how you define words. According to this, java is interpreted (or was) http://java.sun.com/docs/overviews/java/java-overview-1.html But yeah, you have a point about python code not being translated to native machine code like Java. Unless of course, you use psyco with CPython, which generates machine code. Or unless you run Java byte code interpreted, which is also possible. That of course means you can't say something about a specific language without also specifying how the program is executed. – Mattias Nilsson Jun 27 '10 at 21:25
  • That's true, but there's also nothing to stop people from executing C code through an interpreter in which case someone could then say C is an interpreted language. For practical purposes, we describe languages as being interpreted or not based on typical implementations. From a strict language standpoint, languages are neither interpreted nor compiled. – stinky472 Jun 28 '10 at 10:52
  • @stinky472 >> C code through an interpreter << C slower than interpreted Java! http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=cint – igouy Jul 03 '10 at 16:34
  • @stinky472 >> As admitted on the front page, the benchmarks are flawed. << Have you read the "Flawed Benchmarks or Broken Thinking?" page? – igouy Jul 03 '10 at 16:35
  • 1
    @igouy Yes but if we get so pedantic, there's nothing that makes Python slower than C. If someone were to put enough effort into it, they might be able to come up with something comparable in performance, but that just typically doesn't happen. When you have a language that's dynamically typed with mechanisms that can only be implemented at runtime like introspection, there is going to be a runtime cost for it and even the best implementers have not been able to make this cost completely negligible. Maybe some day they'll find a revolutionary new way. – stinky472 Jul 04 '10 at 17:45
  • @igouy "As admitted on the front page, the benchmarks are flawed." No, you don't even have to look that far. Just read what I wrote in the answer where I pointed that out before posting the link. I'm also unsure as to where you are going with this. My point is that, for all practical purposes, if you were to, say, write a raytracer in existing Python implementations, no matter how good you are, you're not going to get comparable speeds to Pixar's Renderman. – stinky472 Jul 04 '10 at 17:46
  • @stinky472 >> Yes but if we get so pedantic << I was just providing a concrete example that substantiates your "there's also nothing to stop people from executing C code through an interpreter". – igouy Jul 04 '10 at 22:12
  • @stinky472 >> I'm also unsure as to where you are going with this << Perhaps what you mean by "flawed benchmarks" is different from the discussion on that webpage. – igouy Jul 04 '10 at 22:15
  • @igouy ah yes. Sorry, I thought maybe you were pointing out a problem with my answer but I wasn't sure exactly what it was. – stinky472 Jul 05 '10 at 13:13
2

C and C++ compile to native code- that is, they run directly on the CPU. Python is an interpreted language, which means that the Python code you write must go through many, many stages of abstraction before it can become executable machine code.

Puppy
  • 138,897
  • 33
  • 232
  • 446
  • It's possible to [compile Python to C++](https://stackoverflow.com/questions/138521/is-it-feasible-to-compile-python-to-machine-code) in some cases, so it can sometimes be just as fast as native code. – Anderson Green Jun 23 '19 at 00:56
0

Python is a high-level programming language. Here is how a python script runs:

enter image description here

The python source code is first compiled into Byte Code. Yes, you heard me right! Though Python is an interpreted language, it first gets compiled into byte code. This byte code is then interpreted and executed by the Python Virtual Machine(PVM).

This compilation and execution are what make Python slower than other low-level languages such as C/C++. In languages such as C/C++, the source code is compiled into binary code which can be directly executed by the CPU thus making their execution efficient than that of Python.

enter image description here

-5

python is interpreted language is not complied and its not get combined with CPU hardware

but I have a solutions for increase python as a faster programing language

1.Use python3 for run and code python command like Ubuntu or any Linux distro use python3 main.py and update regularly your python so you python3 framework modules and libraries i will suggest use pip 3.

2.Use [Numba][1] python framework with JIT compiler this framework use for data visualization but you can use for any program this framework use GPU acceleration of your program.

3.Use [Profiler optimizing][1] so this use for see with function or syntax for bit longer or faster also have use full to change syntax as a faster for python its very god and work full so this give a with function or syntax using much more time execution of code.

4.Use multi threading so making multiprocessing of program for python so use CPU cores and threads so this make your code much more faster.

5.Using C,C#,C++ increasing python much more faster i think its called parallel programing use like a [cpython][1] .

6.Debug your code for test your code to make not bug in your code so then you will get little bit your code faster also have one more thing Application logging is for debugging code.

and them some low things that makes your code faster:

 1.Know the basic data structures for using good syntax use make best code.

 2.make a best code have Reduce memory footprinting.

 3.Use builtin functions and libraries.

 4.Move calculations outside the loop.

 5.keep your code base small.

so using this thing then get your code much more faster yes so using this python not a slow programing language

  • 1
    Welcome to SO. Your points about speeding up Python may be valid, but do not answer OPs question about 'Why are Python Programs often slower than the Equivalent Program Written in C or C++?' – rtx13 Apr 06 '20 at 05:50