Saxon

I've written a test in junit/performance/playground that calls the HTML URI escaper on a few thousand URI-like strings, each containing about 20 ASCII characters followed by one non-ASCII (but BMP) character. Baseline timing is 245.9ms.

Switching off the call to ZenoString.verifySegmentLengths() brings it down to 227.9ms.

Stepping through the execution in the debugger, we're iterating over the code points in the input; most of them are ASCII. We call UnicodeBuilder.append(int) on each one. This wraps the int in a UnicodeCodepoint object (not good news) and calls ZenoString.concat().

UnicodeBuilder is using an underlying ZenoString for convenience and reuse but it's intrinsically not ideal for the task because we don't need an immutable data structure here (we don't need each intermediate string value to be retained and accessible).

At one point UnicodeBuilder "did its own thing" rather than reusing ZenoString, but there was a lot of duplication of code (and bugs) so this was a simplifiication to reduce code and improve reliability, but it's not the best approach for performance.

Probably a rethink of UnicodeBuilder is needed.

I implemented a QuickUnicodeBuilder backed by an int[] array, and use this in place of UnicodeBuilder within the HTMLURLEscaper.

Measured time of my benchmark is down from 227.9ms to 14.6ms.

Clearly a big win for this use case; but I'm not sure the same will be true when we're concatenating existing strings rather than individual characters.

Having established that a different Unicode builder goes much faster, it then occurred to me that there's not really a strong case for using UnicodeString on this path - what happens if we revert to the 10.x code, using String rather than UnicodeString?

Rather to my surprise, the time shoots up again - to 234.6ms.

I can get it down again to 22.5ms simply by replacing the StringBuilder with the new QuickUnicodeBuilder. I have no idea why this should be, but the effect is consistent.

There are about 99 places we create a UnicodeBuilder, and from a quick glance, the vast majority of them fall into the pattern where we're building a fairly short string from individual characters.

I think the next thing to do is test a case like string-join() where we are assembling a string from substrings, to see how the new code compares with the old there.

Doing a string-join of around 48000 20-character strings (with some 2-byte characters but no 3-byte) using the existing UnicodeBuilder takes around 340ms. With the new QuickUnicodeBuilder, it's 12.6ms.

So I'm going to say, let's bite the bullet, and use the new code everywhere.