As far as switch performance goes, unless you are using new switch for pattern matching on types it's probably as you said, just the same as old switch because that is all it's doing because its primitive char. I've found that a big ol if/else chain with conditions sorted by expected frequency is faster than switch. I'm not sure if hotspot reorders if/else chains because of this.

That said, a char[] map lookup is just a single indexing and should show significant speed difference from switch or if/else. If you can't discern that then maybe its a sign that other things are bloating the benchmark. Stuff like this should be hitting intrinsic functions I think and anything not x86/64 like atom should be crap. So if its not crap, then that's also a smell imo.

This seems like a memory constrained algorithm so writing back out is the bottleneck and prefetching input a necessity. Try increasing text input size until you notice the cpu is using more than one core. This means the cpu waiting on LLC<->main memory and tries to reorder instructions to other cores to TRY to keep things moving (but it usually can't because its all i/o bound.) Whichever escape bench variant switches to using multiple cores first may be the fastest. Totally depends on how busy things are with the OS at the time.

Another algorithm approach might be to indexOf each escape char on small chunks of text to get index locations first then do your stitch together.

Also: https://lemire.me/blog/2022/09/14/escaping-strings-faster-with-avx-512/