Dbut I guess those are invalid for ANSI anyways
Pyeah
Pthat's not a valid ANSI string
Pso that's an expected fail
Dwell P/Invoke can do it
Din 130 fucking ns
P¯\_(ツ)_/¯
Pfind out how they're doing it i guess
DI would bet it's compiler magic
Dthere is no way anyone can runtime convert 586 * �� (a 3-byte UTF8 char) in 6.18 ns
Dlike I'm sorry but that's just impossible
Pmeh could be done
Pdunno how
Pbut it doesn't sound that far-fetched
TSeems plausible. Have you spotted the bottleneck yet?
TThe number of bytes on the character doesn't really affect it, as you only need to read the first character to find how many bytes it is.
Dwell I just don't know another way of doing this
Dwe just call into normal system code
Dwhich looks highly optimized
Dbut not 6 ns for almost 600 chars
DCheck with a runtime string. :)
Dlooking at the JIT output rn
DI'd be somewhat surprised if it was roslyn magic
Djit magic seems more likely
TReally depends on where the string you are testing is.
Dwdym?
TWhat is the source of your string.
Da field?
Dbut not sure why that really matters
TWell, the compiler could be emitting the converted string into the text section at compile time.
TWhich would me no conversion is taking place at runtime.
Doh, right, but I'd think that's unlikely
TMurphy laws says otherwise, I would look into it.
Dof course. just going down the list of possible reason right now
D(also looking at the IL, I don't notice anything like that immediately)
TIL isn't what really runs, you would have to check out the native code.
Pyeah fire up windbg
Dyeah that's my step two
Dwhy windbg
Djust JIT disasm
Pidk i just find it the easiest way to disassemble apps as they're running
DYou are not using a debug build to dump your JIT?
Dbut if roslyn did anything here it would be visible in IL
PP/Invoke shims aren't a roslyn thing
Dthey used to be
Pthey never were
DI thought so 
Danyways, if there was some compile time optimization it would be in IL
Dif there is nothing in IL the compiler did nothing
Dso then it has to be JIT