Effectively re-writing the mathtext module does not seem a small project (as I assume the output of the parsing step will be different enough that we will have to re-write the code that consumes it). It might be a good GSOC project?

A less invasive fix would might to add some strategic @functools.lru_cache. Looking at the pdf from the function names it looks like we are doing caching but either the caching is still slow (maybe too many function calls?) or you are generating cache misses. It would be good to sort out which one of those it is.

If your text is not changing frequently you may also get a speed win (at the cost of an expensive first draw) by switching to usetex as we aggressively cache those results.

It is probably not easy to replace the parser, true.

The hot-fix for my app was to remove all LaTeX, which produced a perceivable performance gain.

Some of the LaTeX was static, some was dynamically changing. I did not try to remove only the dynamic components which cannot be cached.