There's a popular error that people make about speed when you see a steady diet of this microbenchmark improving by this many hundred percent and wow, this other effort to speed up is paying off, and so one assumes that the thing in question must be fast now. This is not the case. Something can get many hundreds of these little tiny improvements, but if the underlying architecture is slow and the little microbenchmarks were really just pecking around the edges, the net improvement can end up very small.

This is where CPython lives. CPython has been getting sped up for the last 15 years. The end result is not a blazing fast language knocking the socks of the competition; the end result is that as they've added features, they're been successfully able to more-or-less tread water or make a bit of progress, and they have remained merely one of the slowest languages in common use, instead of unusably slow.

Picking off a few improvements in instruction dispatching in CPython wouldn't have changed Python reposurgeon's capabilities much at all.

The gulf between Python and Go isn't a matter of a few dozen percent, it's a matter of a few dozen times in terms of speed and generally substantial integer multiples on memory use too.

As I said yesterday, many people interpret this as an attack on Python. It isn't. It is just something you need to know to make good engineering decisions. I've used Python many times in the past several years, and I've never been bitten by its performance issues... because I think about it before I use it. It is definitely something you need to think about before you reach for it. It actually was OK for reposurgeon for the most part... it just couldn't handle the largest repos, but those are the exceptions, after all.