The official disclosed a lot of details in the changelog, and one of the "vectorcall" features is the most easily accepted. This article intends to take you first to find out.
In fact, vectorcall has been partially implemented as early as Python 3.8, but it is temporary and hidden, and it is planned to be fully implemented in version 3.9. The following figure is an introduction in version 3.8:
So, what is vectorcall? What changes will it bring?
"A fast calling protocol for CPython", that is, it is a fast calling protocol of CPython, which can accelerate the speed of the CPython interpreter when calling class objects.
(PS: It should be noted that the "protocol" mentioned here is a broad term. It is different from the well-known network protocol or communication protocol. It can be understood as a contract and an implementation method when calling code )
This protocol was proposed in PEP-590 (time is 2019-03-29), the corresponding bpo is issue37207, which took nearly a year of development, and its implementation has been integrated into the code warehouse.
To summarize its core point in one sentence: it will increase the calling speed of main types such as list (), tuple (), dict (), and it can also be used in custom classes.
Combining PEP and bpo information, I have refined the following detailed points:
- vectorcall is the formalization of fastcall. In the previous CPython, there were some scattered optimization points (that is, fastcall), and now they are officially systematized, giving a formal "vectorcall"
- vectorcall works with most built-in types. According to the current disclosure information, it is applicable to the 6 main built-in types of list, tuple, dict, set, frozenset and range (some measurement data shows that the speed increase rate is 10% ~ 30%)
- Vectorcall is a reconciliation of performance and flexibility. The previous interpreter has high flexibility, but in the process of object call, there are unnecessary intermediate objects and indirect call overhead, and now it is managed to eliminate this part of the overhead and improve performance
PEP-590 also introduces the implementation details of CPython in detail, and lists the changes of the C API. This part will not be expanded. Interested students please consult the documentation.
-------- Cat brother broken up the dividing line --------
Even if the main content is finished, it is very simple, not difficult to understand, will not bring the burden of learning, and will not cause any differences of opinion.
But to be honest, this performance improvement may seem a bit "effortless": the speed of the built-in type does not cause any performance problems (not slow), and the improvement space is only nanosecond / microsecond level, very limited. Many core developers spend half a year's time and energy, is it worth it?
We are afraid that none of us are qualified to make a value judgment on this. The benevolence sees benevolence, the wise sees wisdom.
However, perhaps we can think in an optimistic way: For this insignificant performance improvement, core developers can take it seriously, keep improving, continue to invest, and consider comprehensively. So, we have reason to maintain optimistic hope for the future of Python!
-------- Cat brother broken up the dividing line --------
Related Links:
https://www.yixingylzc.cn docs.python.org/3.9/whatsnew/changelog.html
https://www.jiuyueguojizc.cn /dev/peps/pep-0590
https://www.javachenglei.com bugs.python.org/issue37207
