> But I want to continue to understand the code.

You don't have to throw away the original Python codebase.

You can have:

1. An implementation in slow language (i. e. Python) that you maintain manually or semi-manually (with minimal AI assistance) and understand well.

2. A fast implementation that is fully generated and maintained by AI, using slow implementation (1) as a reference.

You can, for example, run two "adversarial" agents, one writes tests that compare output of (1) and (2) and tries to find a discrepancy, the other tries to fix (2) so that its output never differs from (1).

This way, you can be reasonably confident that (2) does exactly the same thing as (1), despite being a blackbox that you don't understand. While (1) remains a reference implementation that you understand well and can work with.

Rust is not your only option. Nor is it automatically the best option, though it is certainly a solid option for a certain set of requirements. Go is a pretty decent match for a Python rewrite; superficially it seems like you're giving up a lot but under the hood they're philosophically more compatible than meets the eye in a lot of ways. But any static language that you have some other local reasons to prefer is going to blow its socks off in terms of performance. And "blow its socks off" is just for the naive translation of a conventional Python code base over to a new language. If your codebase is amenable to threading and can take advantage of multiple CPUs somehow, the result may blow Python's socks off twice over.

The problem is that Python just isn't going to go fast. There are some languages that may have had more resources poured into them to make them go faster in absolute terms, like perhaps Java. But I don't think there's a single language that has had so many ways of trying to make it go faster given so much effort over so many decades. It's really time to call it... if you have Python code and it's a performance problem, if one of the many many many different solutions aren't adequate for some reason, Python is not going to get any faster than it is today and you're going to have to move off of it.

If you need high performance code, Python is simply not the right answer and you're going to have to skill up. Or accept what you have, which you'll have to decide if that's a viable option. If it's fast enough I don't advocate switching casually. But if it isn't, there isn't a realistic prospect that you're going to wake up in a year or two to a 30x-faster Python. I wasn't terribly convinced by that claim back in the early 2000s, but it hadn't really been tested yet. It has been tested now.

You could try having it rewrite parts of the hot path into Rust with PyO3.

There are already many solutions to the performance issue from which you can pick. You don't need to understand the C in numpy to use it for example. And I'd say it's highly unlikely that you have a use case that, if it's applicable, isn't already addressed. Like it's generally pointless to optimize language performance for code that's doing a lot of network operations, because network lag will always dwarf such optimizations.

This works well if there are obvious hot spots that can be easily isolated, but sometimes the perf issues are more uniformly distributed throughout a codebase.