OPINION

The Speed of Python: It Ain’t That Bad!

I hear all the time that Python is way too slow. Is it?

Whether or not Python is slow is more important than some may think. In the opinion article below, you will find a claim that Python’s slowness affects our planet:

Since I did not agree with some of the claims, I responded in the following comment:

In this article, I am going to write my longer opinion about whether or not Python is a slow programming language.

My main languages, those I use to communicate on a daily basis, are Polish, English and Python. When I use Polish, communication is quick and smooth. I think I can say more or less the same about communication in English, even if it’s not that smooth. What about Python?

Python is considered a slow programming language. This means my communication with the other side — when it comes to Python, it’s a machine — is slow and thus inefficient.

Or at least this is what I hear all the time, things like “Python is slow.” “Python is a slow programming language.” “Python is a poor programming language because it’s so slow.” “Python is not a serious programming language. How could it be when it’s that slow?”

If you consider yourself a Pythonista, like me, I guess you hear stuff like that often and it makes you feel uncomfortable. Although I know several programming languages, Python is my main programming language — which is why I care whether or not people consider it a good or bad choice. I want it to be a good choice. And for me, it is.

So, what’s that all about Python being slow? We’ll discuss this topic in this article. This does not mean it will be an extensive and complete analysis of Python’s speed. Instead, I’d like to share my thoughts on this subject with you — but I’ll try to be as objective as I possibly can. Only in this way can I be convincing not only to you, but also to myself.

Benchmarks

The first thing that comes to my mind when I think about speed is benchmarking. When I think about a function or a class or a code snippet in terms of its speed, I like to benchmark it. I wrote two articles about Python benchmarking in terms of execution time:

When it comes to benchmarking Python as a programming language, however, this sort of benchmarking will not help. We need benchmarks of programming languages. I will refer to the benchmarks game:

Any similar benchmarking will do, if only its benchmarks are methodologically correct. There is also nothing wrong in creating and running your own benchmarks, though. I sometimes do this in Linux (actually, in WSL), using the time command. But remember that such small benchmarks are… well, small, and should not be treated as anything convincing or decisive.

As for Python, I would be amazed to see that such benchmarks show it’s not slow. And indeed, the benchmarks game definitely shows that Python is slow. Below, for instance, you can find Python’s benchmarks against C:

It’s difficult to read some of these results without a smile of sadness, though some others do not look that bad. To be honest, I remember that the results were even worse. No wonder: the benchmarks I read today (16 Feb 2023) had been performed in 3.11, and it’s pretty faster than Python 3.10, as follows from this Python 3.11 release highlight:

Even despite Python 3.11 being faster than Python 3.10, we can say that generally, the benchmarks game shows the sad truth about Python, the truth we all know all too well: Python is slow, even if its speed is improving.

But… Is there a but?

If you’ve read some of my texts, you might have noticed that I do not write articles just to complain… In fact, I simply don’t complain about Python — because I like it too much! And indeed, I am not writing this article to complain that Python is slow. On the opposite, I think the situation is much better than many think, and than it follows from such benchmarks and from the discussions all over the net that are related to Python’s speed.

First of all, these benchmarks usually employ heavy numerical computations. Most of us know that if you have heavy computations to perform, using pure (base) Python is not the greatest of ideas — for the simple reason that, yes, such code will be slow. There are tools to make numerical computations in Python fast. We have NumPy, we have SciPy, and we have other tools. Enough to peek into one of the following books, and you will learn that you shouldn’t assess Python’s performance in numerical computations by how base Python performs:

Python offers much more than NumPy and SciPy. We can write C extensions, thanks to which most computations are performed in C. For long-lasting processes being run in C, the overhead cost of the communication between Python and C is relatively small. We have Cython, thanks to which we can write highly optimized C extensions in something I’d call Python’s sublanguage, employing and utilizing the power of static typing. We have highly optimized Python compilers, such as Numba; it can also cooperate with NumPy, making it even faster.

My aim here, however, is not to provide a list of numerical-computation tools or to show how to optimize numerical computation, but to make the following point:

Python is the main machine-learning tool not without a reason: most machine learning algorithms available in dedicated Python frameworks are performed in C. That way, the user gets a simple API in Python along with the speed of C.

Some will say that it’s not Python but C, so I should not be claiming that C extensions make Python fast. I dare to disagree! All languages are written in something, and Python is written in C. What’s the point, then, of saying it’s not Python but C? It is exactly Python, a programming language written in C. The more operations are being performed in C, the better. But it’s still Python.

Using Python means coding in Python. But this does not really mean Python is the last resort communicating with the machine. Python code is translated into bytecode, and eventually what we get is machine code that is executed. Does anyone claim you should code in assembler — which, by the way, is not the final machine code? Of course not. C code does not actually directly communicate with the machine; it’s also translated, through several steps, into machine code. I do not hear complains that C programs are not really C programs because they are translated into machine code, so C’s speed is not really C’s speed.

I think it’s time for an anecdote.

A couple of years ago, I started learning a niche language. When I learned the basics, I implemented some benchmarks against Python and C. The language was considered (by its devotees) fast. Imagine my amazement when I saw that Python was significantly faster in string operations! I tried to rewrite the code, but still, Python did better. I decided to ask in the language’s forum, to learn from the better. So I did, and I was lucky to get an answer from the language’s author.

Did I write I was lucky…? The guy wasn’t too polite, to put it delicately. I will spare you the details. What he wrote about my benchmarks was that they did not make sense — for the simple reason that Python’s string operations are so fast because they’re performed mostly in C, using highly optimized C code. Okay, so Python delegates string operations to C, and…

Sorry, what? So what? I’d say, that’s good! That’s very good that Python does this delegation, isn’t it? I would be happy to have Python as API and all computations being performed in C! We have to remember that a programming language is a sort of API for you to communicate with the machine. What it does under the hood isn’t our concern. (Well, it is, but not for the sake of our discussion.) This discussion and the way the language’s author tried to defend his language made me drop the idea of learning it. Instead, I picked up Go as my secondary programming language, and I have never regretted this decision.

The point of this anecdote is, the more C code is being run by Python, the better for us. It makes Python faster.

I’d like to see Python being as quick as C or C++ or Rust, but that will unlikely happen. But still, Python’s speed is getting better and better. What’s more, we have a lot of tools that make Python really quick, and this is these tools what we can use in many bottleneck parts of the code. They make Python much faster than many think.

Code optimization

Since we’re discussion the speed of Python, I cannot ignore a topic that is crucial to making Python performant: writing good and optimized code. As in any language, in Python you can write good programs and bad programs, and you can write fast programs and slow programs. Sometimes one’s program is slow only because it’s poorly written.

You often can do a lot in terms of code optimization by writing good code. For instance, I once worked on someone else’s code for a data science product. The program did various things, and one of them was creating a table of a dozen or so rows. To this end, the function responsible for this task created a data frame of 40 million rows! Yes, you got this right: 40 millions of rows, or 40_000_000, only to remove almost all of them and keep a dozen of them. Sounds crazy? It was crazy! Not only was the program slow, but it also took a lot of memory; thus, the previous team had to request 32GB of RAM on the production server while the starting memory was 8 GB of RAM. When I eventually understood what was going on in this code (which was not an easy task, believe me), I rewrote this part of code. And you know what? This and other optimizations enabled me to speed up the app by from 12 hours to about 6 hours, despite adding a new big functionality! The 32 GB of RAM were not needed anymore.

The above thought does not refer only to Python, but to any programming language.

This does not mean, however, that you should always optimize your code, by all means. Sometimes it really doesn’t make sense. Would you spend additional five hours to make your script run 5 minutes faster, when this script is to be run only once? Sure you wouldn’t, but it’s a different story, for another evening.

Python is fast… in coding!

When talking about speed, we also need to remember about the speed of coding. Python is exceptional here. Sometimes, you can spend a couple of minutes on writing a program which you would write in a couple of hours in other languages.

Think about a project with a huge code base and a big development team. Now think of using Python for development instead of a language like C++. Using Python could mean tens of thousands of hours less spent on coding! While saving 30 minutes thanks to choosing Python instead of another language does not have to make much of a difference, saving tens of thousands of hours makes a huge difference.

You can also save time thanks to prototyping in Python, even if you use another language for development. As Thomas and Hunt mention in the their fantastic book The Pragmatic Programmer, prototypes are usually thrown out. So, they do not have to be fast to run — but they should be fast to write. We don’t want to spend much time on prototyping itself, and this is where Python is known for its speed — the speed of prototyping.

Conclusion

Pure Python code can be very slow. However, Python offers various tools that enable you to make code faster, especially when numerical computation constitutes the bottleneck. And this is numerical computation where Python is so slow.

Pure Python code can be very fast, when it comes to coding. Sometimes the time saved on coding can be make a difference, so you need to decide what’s more important in your situation: fast coding or short execution time. When you’re prototyping, you definitely need fast coding.

All in all, choose a programming language based on your needs. I don’t think Python deserves the “I’m slow, keep the distance” badge. If you’re hesitating whether or not you should choose Python as your first programming language because you heard it’s slow, stop hesitating. Don’t worry, it’s not that slow; sometimes, it can be even faster than other programming languages. And never forget that what you get at a cost of Python being a little slower is its simple yet rich syntax, very pleasant to both read and write.

Thanks for reading. If you enjoyed this article, you may also enjoy other articles I wrote; you will see them here. And if you want to join Medium, please use my referral link below: