Mark FirstCharInUInt32IsAscii with aggressiveinlining #84306
Conversation
|
Tagging subscribers to this area: @dotnet/area-system-text-encoding Issue DetailsThis small method pops in CPU traces for MinimalApi benchmark. There are two problems here:
I was playing with a fix for inliner but it needs a new JIT-EE API + diffs were huge and needs careful analysis. So for now let's slap an AggressiveInlining on it.
|
| /// </summary> | ||
| /// <param name="value"></param> | ||
| /// <returns></returns> | ||
| [MethodImpl(MethodImplOptions.AggressiveInlining)] |
There was a problem hiding this comment.
Does the JIT do any better by default if it's instead implemented as:
return BitConverter.IsLittleEndian ?
(value & 0xFF80u) == 0 :
(value & 0xFF800000u) == 0;?
There was a problem hiding this comment.
Elsewhere in corelib we'll use:
#if BIGENDIANShould we do the same thing here instead and not rely on the linker at all?
There was a problem hiding this comment.
Probably? I think we'll fix that in JIT's inliner eventually so up to you whatever looks better in code
This small method pops up in CPU traces for MinimalApi benchmark.
With this change I see up ~5% improvement for a simple
Utf8.FromUtf16benchmark for small inputs (<32 bytes).There are two problems here:
BitConverter.IsLittleEndian, see ILLink substitute BitConverter.IsLittleEndian as true constant #83169ldsfld(it's afraid of potential helper calls)I was playing with a fix for inliner but it needs a new JIT-EE API + diffs were huge and needs careful analysis. So for now let's slap an AggressiveInlining on it.