Spanify some Utf8String and Utf8StringBuilder use

[PaulusParssinen]

Address TODO in the Utf8String and Utf8StringBuilder used by ILC and R2R. Saw some potential use for newer more efficient APIs. These are seem to be primarily used by name mangling, which can definitely be improved further.

Let's see if anything breaks in CI first.. Tried to avoid any "public" surface changes because these shared files seem to be used sneakily through the labyrinth of .csprojs s. For example did not rename UnderlyingArray -> UnderlyingSpan and did not try remove the implicit Utf8String -> string casting even though that was a bit of an headache while doing this (changing that is too spooky due to overload resolution).

update: CI seems to be good. Any extra stuff I should be concerned about and try building locally when touching these parts of code?

[neon-sunset]

Now that you are working on this, if you ever have an appetite for public facing API changes (either here or subsequent PR), it is worth changing Utf8StringBuilder to pool arrays, either becoming ValueUtf8StringBuilder (or shorter name) or as is as a start.

[PaulusParssinen]

Now that you are working on this, if you ever have an appetite for public facing API changes (either here or subsequent PR), it is worth changing Utf8StringBuilder to pool arrays, either becoming ValueUtf8StringBuilder (or shorter name) or as is as a start.

I have all sorts of ideas like that; utf8 interpolated string handlers and what not. My first knee-jerk reaction was to look to make either of these a ref struct and actually just have a underlying span. I was gonna hoist Encoding.UTF8 accesses when done multiple times in a method. I was gonna do MaxByteCount instead of GetByteCount. That Append(char) is actually dead code in a way too.

But I'm still paranoid of what is indirectly consuming this API. This won't be last PR so I start with small and try get a feel for what kind of optimizations code owners here feel comfortable with.

[neon-sunset]

utf8 interpolated string handlers and what not

Feel free to steal the code from U8String then if you do go for that, its "default" interpolated string handler pretty much reaches performance ceiling save for special-casing conversion for integers as the path there is a bit heavy but overall fast enough, it beats DefaultInterpolatedStringHandler by ~2x on short lengths. Given this type would still be internal, you could be more aggressive in inline buffer within a struct (I had to tone it down from 256B to 128B and then to just 64B due to stack pressure, copies and state machine size impact).

In the case of ILC it might be worth it to just get a flamegraph first however - good question if it's worth the effort given limited utilization (you can unroll by hand char conversion in a way for JIT to fold it, including the copy, to the correct code point length branch, unroll 1-2-3 byte span copies manually too, etc. - there is a lot of bikeshedding potential).

[jkotas]

Use UTF8 literals for single characters too

I think it would look better to keep Append(char c) method and assert inside the method that c is ASCII char.

[jkotas]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

Thanks