Implement nth for EscapeUnicode

[ranma42]

and cleanup the code for nth for EscapeDefault by sharing the stepping logic between nth and next.

Part of #24214, split from #31049 (last part! :) ).

The test for nth was added in #33103.

[rust-highfive]

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

[ranma42]

Given that he has already reviewed the previous PRs, r? @alexcrichton

[alexcrichton]

This... seems like a lot of code for a pretty minor feature. Out of curiosity is there a crate which is actually exercising this in terms of desiring performance gains or are these just being done for completeness? If they're only done for completeness I'd somewhat prefer to hold off on the extra complexity for now.

[brson]

Is it definitely a perf win?

I spent a while looking at this patch before deciding I didn't understand it enough to review. So I sort of agree with alex that it may not be worth the churn.

[ranma42]

A little less churn would be possible by implementing next as nth(0), but that would result in slightly worse code. Instead both are implemented on top of a step function, which the compiler inlines and constant-folds appropriately. In fact, most of the complexity of the code is related to moving the state switch from next to step so that it can be re-used.

The changes to EscapeDefaultState are merely code cleanup, as they unify the next and nth code paths, instead of keeping them duplicated. No performance change is expected there.

The implementation of nth for EscapeUnicode after this change becomes a simple switch (the same that would be used for next except for the constant offset) with no need to iterate over the successive values, so it would be easy to see major performance wins in artificial benchmarks. Nonetheless, I would be surprised if anybody used nth on EscapeUnicode values in actual code.

I agree that there is little use for this micro-optimisation (especially considered that the offsetting logic is not completely obvious at first sight), so it can probably be held off with no disadvantage.
I would love if it was possible to automatically get this kind of optimisation in generators, but I am afraid it will be very hard because of side-effects.

[alexcrichton]

Ok, in that case it seems fine to close this for now and we can revisit if it becomes a perf hazard for someone?