Python version 3.9.0 is under development, with a final release planned for 2020-10-05.

There are a lot of details in Changelog, but one of the most accepted is the “VectorCall” feature, and this article is going to take you through it first.

In fact, VectorCall was partially implemented in Python 3.8, but it was temporary and hidden, and was scheduled to be fully implemented in 3.9. Here is the introduction in version 3.8:

So what is a Vectorcall? What changes will it bring?

“A fast calling protocol for CPython”, that is, it is a fast calling protocol for CPython that speeds up the CPython interpreter when calling class objects.

(PS: It should be noted that the “protocol” here is a broad term, which is different from the well-known network protocol or communication protocol. It can be understood as a convention and a way of implementation when calling code.)

This protocol was proposed in pep-590 (2019-03-29), corresponding to bpo issue37207, which has been under development for nearly a year and is now implemented in the code repository.

The bottom line is that it speeds up calls to major types like list(), tuple(), dict(), and can also be used on custom classes.

Combining PEP and BPO information, I distilled the following details:

  • Vectorcall is the formalization of FastCall. There were some scattered optimization points (fastCall) in CPython before, but now they are officially systematized and given an official “vectorCall” name
  • Vectorcall works with most built-in types. According to current disclosures, it works with six major built-in types: List, tuple, dict, Set, Frozenset, and Range (some measurements show a 10-30% speed increase)
  • Vectorcall is a blend of performance and flexibility. Previous interpreters were very flexible, but they managed to improve performance by eliminating unnecessary intermediate objects and indirect call overhead during object calls

Pep-590 also describes the implementation details of CPython and lists the changes to the C API, which will not be covered in detail. For those who are interested, please refer to the documentation.

——– Cat brother read fragmentation line ——–

When the main content is introduced, it is simple, not difficult to understand, not burdensome to study, and not divisive.

But to be honest, this performance boost can seem a bit thankless: the call speed of built-in types doesn’t cause any performance problems (it’s not slow), and the improvement is on the nanosecond/microsecond scale, which is very limited. Is it worth the time and effort of multiple core developers?

I’m afraid none of us are qualified to judge the value of that. Different people have different views on the same thing.

However, it is possible to look on the bright side: such trivial performance improvements are taken seriously, refined, consistently invested in, and considered thoroughly by the core developers, and are no less impressive in other ways. So there’s reason to be optimistic about Python’s future!

——– Cat brother read fragmentation line ——–

Related links:

Docs.python.org/3.9/whatsne…

www.python.org/dev/peps/pe…

bugs.python.org/issue37207