Hi Willy, On Mon, Oct 26, 2026 at 11:36:51AM +0100, Willy Tarreau wrote: > I actually think it could be even more efficient to immediately check > after a %XX if the next char is a '%' before deciding to go with > memchr(). Because all UTF-8 encoded text will appear as sequences of > multiple %XX, so calling memchr() to look for a '%' that is already > at the start pointer seems to be a waste of energy. That way the > memchr() call would serve to report the next non-adjacent '%'.
You're right, it is. I added the check and measured it on the same box (EPYC 7413, gcc 8.5.0 -O2, keep-alive, CPU time per request averaged over 120 s runs): 5 kB path, lowercase unreserved escapes 616.1 -> 609.2 us -1.1% 2 kB path, uppercase UTF-8 (output == input) 575.3 -> 571.0 us -0.8% 8 byte path 345.5 -> 344.6 us (noise) That is roughly 2 to 4 ns per memchr() call avoided, which is about what a call that returns on its first byte should cost, so I don't think the lookup itself has more to give. The output is unchanged (300k generated inputs, 3.59M comparisons against v1, no difference). It is in v2, which I'm sending right after this. Thanks, Youngkwang
