It seems unlikely that an ordering comparison could be faster than a check against zero, so I suspect most or all of the speed-up here is coming from performing the usually-false check before the usually-true one.

What performance numbers do you get with just the reordering of the operands to put the character check first?

My other question would be to ask what happens to the assembly output if you explicitly mark "strict" as const with the original code? (the while loop body is long enough that I doubt compilers will be scanning it to see if "strict" is ever actually modified, so the explicit hint may make a difference)

just flipping around the condition makes it 11% faster than vanilla. moving the goto out of the loop gives you another 1% (maybe just because the loop is smaller)

In that case, I'd suggest changing the revised check to be:

if (c <= 0x1f && strict) {
    invalid = next;
    break;
}

And then not re-checking strict outside the loop - just check for invalid >= 0.

(The currently posted version will be much slower when it comes to rejecting bad data, as it will continue a doomed scan, potentially until the end of the file, instead of exiting as soon as it sees an invalid character)

Being slower when rejecting bad data is okay though, since it's going to result in an exception.

Our "even faster" version defers the actual check until after the loop completes, and we keep the minimum seen c throughout the loop (which uses a branchless cmov instruction on Intel-like architectures). That way we only check strict once.

And I believe you're spot on - the performance improvement from simply switching comes because the first condition being false bypasses a couple of branches, whereas before they were being included, and when strict==0 it should make no difference. But avoiding the additional branching entirely is even better.

The last edition looks incorrect to me. Shouldn't break be added after invalid = next?

I am fine with just swapping strict and c <= 0x1f if it gives a noticeable effect (10% or like). We can try more subtle changes (with effect ~ 1%) in a separate issue.

we removed the break on purpose to make the loop as small as possible, the algorithm is still correct

@ncoghlan done as you suggested, just switched around the strict check