Optimize String#to_utf16

[straight-shoota]

This patch contains a series of optimizations to String#to_utf16 to improve performance:

• Remove branches for impossible codepoints. each_char already excludes invalid codepoints, so we only have to handle the encoding as one or two UInt16.
• Drop ascii_only? branch. The performance benefit is questionable because ascii_only? iterates the string. With optimizations to the regular loop, this special case doesn't provide much extra performance, so it's expendable.
• Use pointer appender to avoid bounds checks on every slice assignment. It also improves convenience.
• Use wrapping math operators. These operations cannot overflow, so we can use the unsafe variants for better performance.

[BlobCodes]

Slice#new already guarantees that the returned memory is zeroed out, so this could be removed

..or GC.malloc_atomic could be used to improve performance (+12% for me).

[straight-shoota]

..or GC.malloc_atomic could be used to improve performance (+12% for me).

That's unexpected. Slice(UInt16).new should use malloc_atomic implicitly.
This is not directly obvious, because there's some indirection through the compiler. Pointer.malloc is a primitive and the compiler decides whether that calls GC.malloc or GC.malloc_atomic depending on the type (whether it could contain internal pointers or not).

Can you share the patch for +12% performance?

[BlobCodes]

Slice(UInt16).new should use malloc_atomic implicitly.

Yes, but crystal always zeroes out the memory, even if the GC already guarantees that the memory was zeroed out:

crystal/src/compiler/crystal/codegen/codegen.cr

Line 2174 in 38be359

memset pointer, int8(0), size_t(size)

So atomically allocated memory is always cleared once, non-atomic memory is always cleared twice.
In this case, the memory does not need clearing at all.

Can you share the patch for +12% performance?

- slice = Slice(UInt16).new(u16_size + 1)
+ slice = Slice(UInt16).new(GC.malloc_atomic(sizeof(UInt16).to_u64! &* (u16_size + 1)).as(UInt16*), u16_size + 1)

[straight-shoota]

Gotcha. It's not atomic alloc but the clearing which makes a difference and we can prevent that with GC.malloc_atomic.

[straight-shoota]

I think it's fine to leave this as is.
Explicitly adding a trailing null shouldn't have any significant impact. So it doesn't matter to do it despite the memory being zeroed out. However, it makes sure the algorithm works correctly with non-zeroed memory. We should discuss this in a separate issue (#14687).