This is a work from Big Data Digest, please see the end of the article for reprint requirements.
Author | Nick Humrich
Translated by | Zha Jieqiong, Zhi Chang Yue Ming, Ying Zi
The growth of productivity comes at the cost of sacrificing performance. This article will not discuss the use of asyncio (asynchronous I/O library) in Python, but rather address a question I have been pondering lately: the speed of Python. Compared to those who do not understand Python, I am a loyal fan of Python, and I use it very frequently. Currently, the most common complaint about Python is its slow execution speed. Generally, most people refuse to use Python because it is slower than some other languages. Nevertheless, I still recommend using Python for the following reasons:
Speed is no longer important
In the past, running programs took a long time. CPUs and memory were quite expensive, and a key metric for these two hardware components was the time taken to run programs. The cost of computers and the electricity required to run them was also very high. To optimize these resources, one must adhere to an eternal business principle:
Optimize the most expensive resource
Historically, the most expensive resource has undoubtedly been computer runtime. This led computer science to focus on researching the efficiency of different algorithms. However, as silicon has become cheaper, everything has changed. Runtime is no longer the most expensive resource. The most expensive resource for businesses today is employee time. In other words, it is more important to have employees complete programs within a set timeframe than to make the programs run faster. In fact, this is crucial, and I reiterate it here to introduce the following content (for those who just want to skim the article):
The development time of a program is more important than its runtime speed.
You might say, “My company only cares about speed; all the response times of the web programs I develop are faster than those in other languages by a few milliseconds.” Or, “Our customers cancel orders because they feel our programs are too slow.” I am not saying that speed is unimportant, but rather that it is no longer the most critical issue and is no longer the most expensive resource.
Speed! Is the only important thing
The speed you perceive in a programming environment actually refers to performance, i.e., CPU cycles (machine cycles). What your BOSS refers to as speed in the programming environment is the speed of company operations, with the most important metric being time to market. Ultimately, regardless of how fast your product or web application runs, what language it is written in, or how much it costs to run, at the end of the day, what determines your company’s survival is when you go to market. I am not just talking about how long it takes for a startup idea to become profitable, but the entire timeline—”from idea to final delivery.” The only way for a business to survive is to innovate faster than your competitors. No matter how many good ideas you come up with, once your competitors implement them before you, everything is in vain. You must be the first to market or at least stay ahead. If your innovation speed slows down, you may be doomed.
The only way to survive in business is to innovate faster than your competitors.
Case Study: (Microservices Architecture)
Companies like Amazon, Google, and Netflix (a paid video streaming service in the U.S.) are well aware of the importance of rapid development. They have created a business system to facilitate faster growth and innovation. Microservices architecture has solved their challenges. This article does not intend to recommend that you use microservices architecture, but at least to help you understand why Amazon and Google should use this architecture.
Microservices architecture has always been relatively slow; it breaks the limitations of network calls. This means that you turn function calls (a set of CPU cycles) into network calls. I believe there is no worse experience than this. Compared to CPU calls, network calls are incredibly slow. Although I believe no architectural program is slower than this, these large companies still choose to use microservices architecture. The biggest drawback of microservices architecture is performance, while the biggest advantage is time to market. By building teams around small projects and codebases, companies can iterate and innovate faster. This shows that not only startups but also large companies care about time to market.
CPU is not your bottleneck
If you write an application, such as a web server, it is possible that CPU time is not your biggest challenge. When your web server processes a request, it may generate a series of network calls, such as those involving a database or a caching server like Redis. Although these services respond quickly, their network calls can be slow. A good blog points out the speed differences in certain operations. In this article, the author explains CPU cycle times in human time; if a single CPU cycle takes one second, a network call from California to New York would take four years—too slow! Roughly estimating, if a typical network call within the same data center takes 3 milliseconds, that is equivalent to 3 months in our “human time.” Now, suppose your program is CPU-intensive and requires 10,000 cycles to respond to a call; that would take more than a day. If the language you are using is 5 times slower, it would now take about 5 days. Of course, compared to a 3-month network call, an additional 4 days doesn’t make much difference. If someone has to wait at least 3 months for a data packet, I don’t think waiting an extra four days would matter much to them.
The final conclusion is: even if Python is slow, it doesn’t matter much. The speed of the language (or CPU time) is almost never the issue. Google has actually conducted a study on this concept and published a research report discussing the design of high-throughput systems.
In summary, using interpreted languages in high-throughput environments seems absurd. However, we find that CPU time is basically not a limiting factor. The expressiveness of the language means that most programs are relatively small, and most of the time is spent on I/O read/write and code execution. Additionally, flexible interpreted languages help both in terms of language-level implementation and in exploring distributed computing methods across many machines. In short—
CPU time is almost never a limiting factor!
If CPU time is a problem?
You might say, “This conclusion is great. But we do encounter CPU limitations, which cause our web applications to run very slowly,” or “Using a certain language on the server requires less hardware support than other languages.” Such situations can indeed occur. But the advantage of web servers is that you can load balance infinitely. In other words, you can add more hardware. Of course, Python may require more hardware than languages like C. Solve CPU issues with hardware; hardware is much cheaper than your time. If you can save a few weeks of work time in a year, its value will exceed the additional hardware costs.
So, is Python faster?
In this article, I have been discussing that development time is the most important. So there is another question: Is Python faster than other languages during development? Interestingly, I, Google, and some others can demonstrate that Python is more efficient. It can simplify many things for you, helping you focus on the code you really want to implement rather than getting bogged down in trivial matters like whether to use vectors or arrays. But you might not believe what I say, so let’s look at some data:
Most of the time, the debate about whether Python is more efficient can be reduced to a conflict between scripting languages (or dynamic languages) and static languages. I think it is generally accepted that static languages are less efficient. However, there is a great paper that explains why this is not the case. Specifically for Python, there is a study that summarizes the time required to write string processing programs in various languages.
The time required by different programming languages to write string processing programs
The above study shows that within the same time frame, Python’s output is more than twice that of Java, and many other studies have reached the same conclusion. Rosetta Code (a wiki site that solves the same task in different languages) once conducted an in-depth study on the differences between programming languages, and in the study, they compared Python with other scripting/interpreted languages, concluding that “Python is often the most concise language, even rivaling functional programming languages (with an average writing time saving of 1.2 to 1.6 times compared to other languages).”
Overall, the lines of code in Python are usually quite short. Although line count seems like a poor metric, many studies, including the one mentioned earlier, indicate that the runtime of each line of code is roughly the same across all programming languages. Therefore, fewer lines of code increase the productivity of programs. Even coding horror (Jeff Atwood, a C# programmer) has written an article discussing how high the productivity of Python code is.
In my opinion, it is appropriate to say that Python is more productive than all other languages, mainly because Python has many built-in modules and numerous third-party libraries. There is an article on the official Python website discussing the differences between Python and others (https://www.python.org/doc/essays/comparisons/). If you don’t know why Python is so lightweight and efficient, I recommend taking this opportunity to learn some Python and explore it yourself. Here is your first program:
import __hello__
If speed is really important, what then?
It may sound like the above argument suggests that optimization and runtime speed are not important at all, but the fact is that in many cases, program performance is indeed very important. For example, you have a web application where a terminal takes a long time to respond. You know how fast it needs to be and how much improvement is needed.
In this example, the following occurs:
-
We found a terminal that responds very slowly.
-
We found it was slow because we had a standard to measure what is considered fast enough, but this terminal did not meet the standard.
We do not need to make tiny optimizations to everything in the application; we just need to make each part fast enough. Your users may notice that a terminal takes several seconds to respond, but they will not notice if you reduce the response time from 35 milliseconds to 25 milliseconds. “Good enough” is all you need to achieve. Disclaimer: I should point out that there are indeed some applications, such as real-time bidding programs, that require tiny optimizations, and every millisecond matters. But that is an exception and should not be the rule.
To understand how to optimize a terminal, the first step you should take is to look at the entire program and try to identify where the speed bottlenecks are, after all, Gene Kim said,
“Optimizing programs not at the speed bottleneck is all fluff.”
If your optimization is not at the most needed place in the entire program, you are wasting your time. Unless you optimize at the bottleneck, your program will not see substantial speed improvements. If you start optimizing before identifying the bottleneck, it is like playing whack-a-mole with your code, and this kind of optimization done before finding and confirming the bottleneck is called premature optimization. There is a saying that criticizes this behavior; many people believe this saying is from Donald Knuth, but he himself said it was borrowed from others: “Premature optimization is the root of all evil.”
When it comes to maintaining codebases, Donald Knuth’s original words are:
“In 97% of cases, we should ignore small efficiency improvements; that is, premature optimization is the root of all evil, but we should not miss that critical 3%.”
In other words, he is saying that in most cases, you should not always think about optimizing your code; it is almost good enough. When your code is not good enough, we usually only need to change 3% of the code. Making your terminal respond a few nanoseconds faster will not yield any benefits because you might just be replacing a function with an if statement. So after you have figured out where the bottleneck is, then optimize the code.
Premature optimization includes calling a faster method or even using a faster data structure. Computer science shows that if two methods or algorithms have the same asymptotic growth rate (or big O), then they are the same, even if one is twice as fast in practical use. The speed of computers is so fast that the increase in computational load due to data growth is more important than the actual computation speed. In other words, if we have two functions of O(log n), but one is twice as slow as the other, it doesn’t matter because as the data size increases, they will slow down at the same rate. This is why “premature optimization is the root of all evil”; this kind of optimization wastes our time and never truly improves computation speed.
From a big O perspective, you can think of all programming languages as O(n) level algorithms, where n is the number of lines of code or instructions. The fact that a programming language or program runs slowly is not an issue; from the perspective of asymptotic growth rates, all programming languages are born equal. From this logic, you can consider choosing a programming language for an application based on the “speed” factor to be premature optimization; you are actually choosing a language that is “supposedly” fast without testing or understanding what the bottlenecks affecting speed are.
Choosing a programming language for an application based solely on the “speed” factor is entirely premature optimization.
Optimizing Python
One thing I love about Python is that it allows you to optimize your code a little bit each time. Suppose you find that a method implemented in Python is limiting the speed of your code, and you might refer to Python speed or Python performance guides to optimize the code multiple times; you are now very sure that Python itself is the bottleneck in runtime speed. But Python can call C code, which means you can rewrite that part of the code in C to improve performance, allowing you to rewrite one method at a time. This process allows you to focus on Python most of the time, only using lower-level languages when you really need to.
There is a programming language called Cython, which is a superset of Python. It can be roughly considered a fusion of Python and C; it is an incremental language. Any Python code is valid Cython code, and Cython can be compiled into C code. With Cython, you can write a module or method and gradually form more C-type files and executables, and you can blend C types with Python’s duck typing (a style of dynamic typing). With Cython, you can only integrate optimized code at the bottlenecks and keep the beauty of the Python language elsewhere.
Screenshot from EVE Online: a space MMO game written in Python.
When you finally encounter performance issues with Python, you do not need to rewrite all the code in another language. You only need to rewrite a few methods in Cython to achieve satisfactory performance, which is the strategy used by EVE Online. EVE Online is a massive multiplayer online game that uses Python and Cython as its entire architecture, achieving game-level performance by optimizing bottlenecks with C and Cython. If this optimization approach works for EVE Online, it can meet the needs of most people. Additionally, there are other ways to optimize your Python programs. For example, PyPy is a JIT (Just-In-Time) implementation of Python. For long-running programs (like web servers), switching from Cython (the default implementation of Python) to PyPy can significantly reduce runtime.
Let’s recap some key points:
-
Optimize your most expensive resource, which is you! Not the computer.
-
Choose a language/framework/architecture that allows for rapid development (like Python). Do not choose technologies that are merely fast.
-
When you do have performance issues, find where the bottlenecks in your program are.
-
The bottleneck of a program is usually not the CPU or the Python language itself.
-
If Python itself becomes the bottleneck of program execution (after you have optimized your code), then you can switch to popular Cython or C.
-
Enjoy the joy of getting things done quickly.
Scanto register for the Strata Data Conference
Big Data Digest exclusive offer ends May 5
Source: https://hackernoon.com/yes-python-is-slow-and-i-dont-care-13763980b5a1
Reprint instructions
For reprints, please prominently indicate the author and source at the beginning of the article (reprinted from: Big Data Digest | bigdatadigest), and place a prominent QR code for Big Data Digest at the end of the article. Articles without original identification can be edited according to reprint requirements and can be directly reprinted. After reprinting, please send us the reprint link; for articles with original identification, please send [Article Name - Public Account Name and ID to be authorized] to apply for whitelist authorization. Unauthorized reprints and adaptations will be pursued legally. Contact email: [email protected].
Volunteer Introduction
Reply “Volunteer” to learn how to join us
Previous Exciting Articles
Click the image to read the article
45 Regression Questions Every Data Scientist Should Know (with Answers)
