It feels a little embarrassing that I could speed up URL (percent) encoding in #curl 500% with this: https://github.com/curl/curl/pull/22780
@bagder nice optimization. Another way to write this might've been to use `strspn`/`strcspn`. Depending on how many characters end up in the accept/reject set `clang` used to be able to do some pretty impressive optimizations on that (IIRC if the accept set < 64 and in a zone of 64 contiguous chars, then it can be implemented with a shift and bitmask test). Although that might be brittle because you can't be sure the optimization will kick in, and if not then the library function may be slower, also I haven't checked whether that optimization would be possible for the particular accept set here. You could see the optimized assembly and translate it back to C manually though :)
@bagder
oh, so the compiler wasn't vectorizing the char-by-char loop you had, so you switched to using memcpy/memchr whole batches of non-special characters because the compiler can vectorize the inside of those?
@bagder
Is this due to whatever ISUNRESERVED (a macro, I presume) does?
Replaced with a lookup table?
Not going to tell you how to write, but:
reject_limit = (ctrl == REJECT_CTRL) ? 0x20 :
(ctrl == REJECT_ZERO) ? 1 : 0;
…makes me itch, because years back I started putting the constant as the lvalue of equality tests for that rare/frequent mistake of dropping an '=' and creating an accidental assignment…
I know it messes with readability for some people…
@RealGene I did that a while in the past too, but compilers don't let you do those mistakes anymore. This is the way most people prefer to read comparisons I've learned.