Python, at least in the CPython reference implementation, is not a particularly speedy language. That is not at all surprising to anyone who has used it—the language is optimized for understandability and development speed, instead. There have been lots of efforts over the years to speed up various parts of the interpreter, compiler, and virtual-machine bytecode execution, though no comprehensive overhaul has been merged into CPython. An interesting new proposal could perhaps change that, though it is unclear at this point if it will take off.

Mark Shannon posted a message about his ideas to the python-dev mailing list in late October. He noted that CPython is slow, "yet little is done to fix it"; he would like to change that. He has a four-phase plan to get there on the technical side, along with some ideas on how to fund the effort. Beyond that, he had some thoughts on what was different from earlier efforts:

He pointed those interested to a GitHub repository where he had placed a few documents describing the plan. The overall idea is for each phase to increase CPython performance by 50%, which results in a 5x speedup at the end of all four phases. The intent is for these improvements to apply widely: "Performance should improve for all code, not just loop-heavy and numeric code." He described a tiered execution model that would separate code into tiers based on how frequently it runs; each tier would be handled differently:

The funding plan is rather creative and different, but also seems to be drawing some scrutiny—and perhaps controversy. Each phase would require roughly $500,000; half of that would be used to pay for the development and the other half would be held by the organization that is coordinating the funding for use in the maintenance of CPython. He suggests the Python Software Foundation (PSF) as the obvious choice for that role.

In order to reduce the risks of a contractor for a specific phase being unable to deliver the specified performance increase, payment would only be made on delivery. For the first phase, Shannon has working code, so he is essentially suggesting that the PSF raise the funds to engage him as the contractor for that phase. But that approach raised the eyebrows of Steven D'Aprano:

He went on to ask what happens to the code if the PSF decides not to pursue the idea. Shannon did not directly address that question, but he is trying to negotiate a business deal of sorts:

Chris Angelico wondered about Shannon's plan for phase two, which is envisioned as a grab bag of fairly small improvements: "you're proposing a number of small tweaks in stage 2 and expecting that (combined) they can give a 50% improvement in overall performance?" But Shannon pointed out that compounding helps here: "20 tweaks each providing a 2% is a 49% speedup."

Also, as D'Aprano noted, each phase stands on its own. No commitment would need to made for phase two until phase one has been delivered (and been paid for). Then if Shannon was unable to achieve the 50% performance increase for phase two, as Angelico worries, Shannon would not be paid for that work. There is some wiggle room in the proposal, D'Aprano pointed out, so that getting a 49% increase would still result in payment, perhaps on "some sort of sliding scale".

Angelico also asked if the $2 million might be better spent on improving PyPy. Shannon said that there is a difference in what partial success would mean for the different projects. The main hurdle for PyPy as a replacement for CPython is getting the C extensions to work; a partial solution to that problem only goes so far:

Paul Moore was generally in favor of the proposal if someone could be found to fund it. But it is important to ensure that the usual development workflow, including code review, pull requests, and so forth, is going to be followed, he said. While Shannon did not directly reply to that message, elsewhere in the thread he made it clear that he plans to handle these changes in the normal fashion. In fact, both he and Moore said that some of the money might be used to pay for code review.

Gregory P. Smith was favorably inclined toward the idea as well. Shannon is effectively proposing a path toward bringing ideas from his earlier HotPy (2) project to CPython "with an intent to help maintain them over the long term", Smith said. He believes the terms are quite reasonable, with regard to both the money and the risk protections; it is a good fit for CPython:

The Python steering council also weighed in. Thomas Wouters posted a lengthy reply in early November that relayed some of the council discussion of the idea. The council is not opposed to the idea at all, but does caution that there are a lot of details that need to be worked out before it could make a serious effort to find an entity or entities to fund phase one. There is also a question of prioritization:

Shannon replied that he had not yet made a proposal to the council but was glad to get the feedback. He agreed that maintenance is an important priority, which is why he included money for that in his proposal, but that it will be easier to justify performance improvements to potential funding entities:

He also said that the total amount of code being added to CPython is not that large and that he hopes to offset any complexities in the implementation with better organization of the code base.

It is an ambitious proposal that was generally met with approval, even if the "show me the money" funding model is somewhat unorthodox. It is not entirely clear where things go from here, but it would seem a bit sad to miss out on an opportunity to make such a large difference in CPython performance. For many Python-using companies, $500,000 (or even $2 million) is not much of a stretch financially—gathering a few of them together should make that even easier. With luck, some discussions are already underway.

(Log in to post comments)