I imagine a future world where we ship a PHP extension ourselves that includes C implementations of base85, a lot of utf8 stuff, etc., (T2312) but I'm hesitant to start adding optional PHP extension dependencies before that, at least without a stronger use case. One specific concern is that if PHP segfaults it's hard to figure out why (and I actually don't even know how to pull a backtrace out of an Apache coredump reliably), so I feel under-equipped to support new extensions. There's also a general lack of other peripheral support today, like reporting installed extensions in Config > Versions.

The next change here should also just totally moot this by making the renderer bail early way before we get to this code, which is the actual intended attack on the problem the install hit.

That particular extension also just does the inner base85 bit, not the Git encoding around it. The inner bit is more expensive so it would get most of the possible improvement, but the entire function could easily go to C for an even larger improvement.

This change and D19407 are ultimately super low-impact to the point of being kind of pointless, I just thought this was like 300x slower than it is based on assumptions from the original report and by the time I figured out it apparently isn't that slow I already more or less had a slightly faster version of it. I could kind of just throw this and D19407 out, but it feels like the test coverage is in a slightly better place now, maybe? And it's a bit faster and I think not particularly more complex.

We'd also want to make a similar structural change to the tests if we did add extension support (since we'd need to keep the PHP version around, and that would let the unit tests check that the PHP version and C version have the same behavior) so maybe that's a good argument for these changes, too.