Yes, Python is slow, but I don't care
Talk about reducing productivity for productivity.
I take a pause in my discussion of asyncio in Python to talk about the speed of Python. Let me introduce myself, I am an ardent fan of Python, and use it wherever I can. One of the reasons why people oppose this language is that it is slow. Some refuse to even try to work on it just because "X is faster." Here are my thoughts on this.
Previously, programs were run for a very long time. Processor and memory resources were expensive, and work time was an important indicator. And how much they paid for electricity! However, those days are long gone, because the main rule is:
You might argue: “My company cares about speed. I create a web application in which all the answers come in less than x milliseconds ”or“ customers left us because they thought our application was too slow. ” I'm not saying that the speed of work is not important at all, I just want to say that it has ceased to be the most important; this is not your most expensive resource.
')
When you use the word "speed" in the context of programming, most likely you mean CPU performance. But when your CEO uses it as applied to programming, he means business speed. The most important metric is time to market. In the end, no matter how fast your products work, no matter what programming language they are written in or how many resources are required for their work. The only thing that will make your company survive or die is time to market. I’m not talking anymore about how quickly the idea will start generating revenue, but about how quickly you can release the first version of the product. The only way to survive in business is to grow faster than competitors. It doesn't matter how many ideas you have if competitors implement them faster. You must be first in the market, or at least keep up. Slightly slow down - and perish.
Large companies, such as Amazon, Google or Netflix, understand the importance of rapid development. They specifically build their business so that they can quickly innovate. Microservices help them with this. This article has nothing to do with whether you should build your architecture on them, but at the very least agree that Amazon and Google should use them. Microservices are slow in nature. Their very concept is to use network calls. In other words, instead of calling a function, you go for a walk around the network. What could be worse in terms of performance ?! Network calls are very slow compared to CPU cycles. However, large companies still prefer to build an architecture based on microservices. I really don't know what could be slower. The biggest disadvantage of this approach is performance, while the plus will be time to market. By creating teams around small projects and code bases, a company can iterate and innovate much faster. We see that even very large companies care about time to market, and not just start-ups.
If you are writing a network application, such as a web server, the processor is most likely not the bottleneck of your application. During the processing of the request, several network calls will be made, for example, to a database or cache. These servers can be arbitrarily fast, but everything will rest on the speed of data transmission over the network. Here is a really cool article that compares the execution time of each operation . In it, the author counts one second per clock of the processor. In this case, the request from California to New York will stretch for 4 years. Here is such a slow network. For approximate calculations, we assume that data transmission over the network inside the data center takes about 3 ms, which is equivalent to 3 months on our scale of reference. Now take a program that loads the CPU. Suppose she needs 100,000 cycles to process one call, it will be equivalent to 1 day. Suppose we write in a language that is 5 times slower - it will take 5 days. For those who are willing to wait for 3 months, the difference in 4 days is not so important.
Ultimately, the fact that python is slow no longer matters. The speed of a language (or processor time) is almost never a problem. Google described it in his research . And there, by the way, refers to the development of a high-performance system. In conclusion, come to the following conclusion:
In other words:
What about these arguments: “Everything is fine, but what if the CPU becomes a bottleneck and does it start to affect performance?” Or “The language x is less demanding on hardware than y”? They also have a place to be, but you can scale the application horizontally infinitely. Just add servers, and the service will work faster :) Without a doubt, Python is more picky about hardware than the same C, but the cost of the new server is much less than the cost of your time. That is, it will be cheaper to buy additional resources, and not to rush to optimize something every time.
Throughout the article, I kept saying that the most important thing was developer time. So the question remains: is Python X faster during development? It's funny, but I, Google and some others , can confirm how productive Python is. He hides so many things from you, helping to focus on your main task and not being distracted by any trifles. Let's look at some examples from life.
For the most part, all the controversy surrounding Python performance is tied to a comparison of dynamic and static typing. I think everyone will agree that statically typed languages are less productive, but just in case, here’s a good article explaining why. As for Python itself, there is a good research report that examines how long it took to write code to process strings in different languages.
In the above study, Python is more than 2 times more productive than Java. Many other programming languages also give similar results. Rosetta Code conducted a fairly extensive study of the differences in the study of programming languages. In the article, they compare python with other interpreted languages and state:
Apparently, a Python implementation will usually have fewer lines of code than in any other language. This may seem like a terrible metric, but several studies , including those mentioned above, show that the time spent on each line of code is about the same in each language. Thus, the fewer lines of code, the greater the productivity. Even the codinghorror itself (a C # programmer) wrote an article that Python is more productive.
I think it is fair to say that Python is more productive than many other programming languages. This is mainly due to the fact that it comes "with batteries", and also has many third-party libraries for all occasions. Here is a small article comparing Python and X. If you don't believe me, you can see for yourself how simple and convenient this programming language is. Here is your first program:
, . . , - endpoint, . . :
- . « ». , , 35 25 . « ».
, . :
, . , . , , . « » — - . . , , :
, , . :) , , 3% , . , .
, , < . , > - . , Big-O, . 2 . , . , O(log n), , . . — ; .
Big-O O(n), n — - . , — . <. . , X Y, > , «» , .
Python, , . , Python, . , , , , Python . C, , C, . .
, , Python .
Cython, Python. C. Python Cython, C. C . Cython, , . , , EVE Online. MMoRPG Python Cython , , . , . , PyPy — JIT Python, (, -), CPython ( ) PyPy.
, :
!
I take a pause in my discussion of asyncio in Python to talk about the speed of Python. Let me introduce myself, I am an ardent fan of Python, and use it wherever I can. One of the reasons why people oppose this language is that it is slow. Some refuse to even try to work on it just because "X is faster." Here are my thoughts on this.
Performance is no longer important.
Previously, programs were run for a very long time. Processor and memory resources were expensive, and work time was an important indicator. And how much they paid for electricity! However, those days are long gone, because the main rule is:
Optimize the use of your most expensive resources.Historically, the most expensive was the processor time. This is precisely what is brought up when studying informatics, focusing on the effectiveness of various algorithms. Alas, this is no longer the case - iron is now cheaper than ever, and after it the execution time is getting cheaper. The most expensive is the time of the employee, that is, you. It is much more important to solve the problem, rather than speed up the execution of the program. I repeat for those who just leaf through the article:
It is much more important to solve the problem, rather than speed up the execution of the program.
You might argue: “My company cares about speed. I create a web application in which all the answers come in less than x milliseconds ”or“ customers left us because they thought our application was too slow. ” I'm not saying that the speed of work is not important at all, I just want to say that it has ceased to be the most important; this is not your most expensive resource.
')
Speed is the only thing that matters.
When you use the word "speed" in the context of programming, most likely you mean CPU performance. But when your CEO uses it as applied to programming, he means business speed. The most important metric is time to market. In the end, no matter how fast your products work, no matter what programming language they are written in or how many resources are required for their work. The only thing that will make your company survive or die is time to market. I’m not talking anymore about how quickly the idea will start generating revenue, but about how quickly you can release the first version of the product. The only way to survive in business is to grow faster than competitors. It doesn't matter how many ideas you have if competitors implement them faster. You must be first in the market, or at least keep up. Slightly slow down - and perish.
The only way to survive in business is to grow faster than competitors.
Let's talk about microservices
Large companies, such as Amazon, Google or Netflix, understand the importance of rapid development. They specifically build their business so that they can quickly innovate. Microservices help them with this. This article has nothing to do with whether you should build your architecture on them, but at the very least agree that Amazon and Google should use them. Microservices are slow in nature. Their very concept is to use network calls. In other words, instead of calling a function, you go for a walk around the network. What could be worse in terms of performance ?! Network calls are very slow compared to CPU cycles. However, large companies still prefer to build an architecture based on microservices. I really don't know what could be slower. The biggest disadvantage of this approach is performance, while the plus will be time to market. By creating teams around small projects and code bases, a company can iterate and innovate much faster. We see that even very large companies care about time to market, and not just start-ups.The processor is not your bottleneck
If you are writing a network application, such as a web server, the processor is most likely not the bottleneck of your application. During the processing of the request, several network calls will be made, for example, to a database or cache. These servers can be arbitrarily fast, but everything will rest on the speed of data transmission over the network. Here is a really cool article that compares the execution time of each operation . In it, the author counts one second per clock of the processor. In this case, the request from California to New York will stretch for 4 years. Here is such a slow network. For approximate calculations, we assume that data transmission over the network inside the data center takes about 3 ms, which is equivalent to 3 months on our scale of reference. Now take a program that loads the CPU. Suppose she needs 100,000 cycles to process one call, it will be equivalent to 1 day. Suppose we write in a language that is 5 times slower - it will take 5 days. For those who are willing to wait for 3 months, the difference in 4 days is not so important.
Ultimately, the fact that python is slow no longer matters. The speed of a language (or processor time) is almost never a problem. Google described it in his research . And there, by the way, refers to the development of a high-performance system. In conclusion, come to the following conclusion:
The decision to use an interpreted programming language in high-performance applications may be paradoxical, but we are faced with the fact that CPU is rarely a deterrent; The expressiveness of the language means that most programs are small and most of the time is spent on I / O, and not on its own code. Moreover, the flexibility of the interpreted implementation was useful, both in the simplicity of experiments at the linguistic level, and in giving us the opportunity to explore the ways in which calculations are distributed across many machines.
In other words:
CPU is rarely a deterrent.
What if we still run into the CPU?
What about these arguments: “Everything is fine, but what if the CPU becomes a bottleneck and does it start to affect performance?” Or “The language x is less demanding on hardware than y”? They also have a place to be, but you can scale the application horizontally infinitely. Just add servers, and the service will work faster :) Without a doubt, Python is more picky about hardware than the same C, but the cost of the new server is much less than the cost of your time. That is, it will be cheaper to buy additional resources, and not to rush to optimize something every time.
So, is Python fast?
Throughout the article, I kept saying that the most important thing was developer time. So the question remains: is Python X faster during development? It's funny, but I, Google and some others , can confirm how productive Python is. He hides so many things from you, helping to focus on your main task and not being distracted by any trifles. Let's look at some examples from life.
For the most part, all the controversy surrounding Python performance is tied to a comparison of dynamic and static typing. I think everyone will agree that statically typed languages are less productive, but just in case, here’s a good article explaining why. As for Python itself, there is a good research report that examines how long it took to write code to process strings in different languages.
In the above study, Python is more than 2 times more productive than Java. Many other programming languages also give similar results. Rosetta Code conducted a fairly extensive study of the differences in the study of programming languages. In the article, they compare python with other interpreted languages and state:
Python, in general, is the most concise, even in comparison with functional languages (on average, 1.2-1.6 times shorter).
Apparently, a Python implementation will usually have fewer lines of code than in any other language. This may seem like a terrible metric, but several studies , including those mentioned above, show that the time spent on each line of code is about the same in each language. Thus, the fewer lines of code, the greater the productivity. Even the codinghorror itself (a C # programmer) wrote an article that Python is more productive.
I think it is fair to say that Python is more productive than many other programming languages. This is mainly due to the fact that it comes "with batteries", and also has many third-party libraries for all occasions. Here is a small article comparing Python and X. If you don't believe me, you can see for yourself how simple and convenient this programming language is. Here is your first program:
import __hello__, ?
, . . , - endpoint, . . :
- endpoint,
- ,
- . « ». , , 35 25 . « ».
, , , , . , .
, . :
, - , . — .
, . , . , , . « » — - . . , , :
— ., :
, , 97% : — . 3%.
, , . :) , , 3% , . , .
, , < . , > - . , Big-O, . 2 . , . , O(log n), , . . — ; .
Big-O O(n), n — - . , — . <. . , X Y, > , «» , .
Python
Python, , . , Python, . , , , , Python . C, , C, . .
, , Python .
Cython, Python. C. Python Cython, C. C . Cython, , . , , EVE Online. MMoRPG Python Cython , , . , . , PyPy — JIT Python, (, -), CPython ( ) PyPy.
, :
- — , ;
- //, . , ;
- — , ;
- , , Python;
- Python ( ), Cython/C;
- .
!
Source: https://habr.com/ru/post/329988/
All Articles