Investigate GetUnicodeCategory performance for non-ASCII characters

[Copilot]

Description

Investigated the reported 1-3ns regression in char.GetUnicodeCategory(char) for non-ASCII characters since .NET 5.0. The original issue suggested calling CharUnicodeInfo.GetUnicodeCategory(char) instead of CharUnicodeInfo.GetUnicodeCategory((int)c) to avoid a redundant IsValidCodePoint check.

Changes

Two approaches were attempted and benchmarked via EgorBot:

1. Char overload change: Changed Char.GetUnicodeCategory(char c) to call CharUnicodeInfo.GetUnicodeCategory(c) (char overload) instead of CharUnicodeInfo.GetUnicodeCategory((int)c) (int overload)
2. AggressiveInlining: Added [MethodImpl(MethodImplOptions.AggressiveInlining)] to CharUnicodeInfo.GetUnicodeCategory(char)

Both changes were reverted after benchmark results showed they caused a regression rather than an improvement.

Benchmark Results

EgorBot results (run 1, run 2):

x64 (AMD EPYC 9V74): PR was 1.88x slower across all non-ASCII characters:

Method	Main	PR	Ratio
Hebrew	0.29 ns	0.55 ns	1.88
Arabic	0.29 ns	0.55 ns	1.89
Chinese	0.29 ns	0.55 ns	1.88
Cyrillic	0.29 ns	0.55 ns	1.88

ARM64 (Neoverse-N2): Neutral (ratio ~0.98-1.02).

Adding AggressiveInlining made no difference — both runs produced identical x64 results.

Analysis

The JIT already optimizes the (int)c → CharUnicodeInfo.GetUnicodeCategory(int) path extremely well. The IsValidCodePoint check is trivially eliminated for char-width values, and the resulting code is more efficient than routing through the char overload. Main's ~0.29ns is already ~10x faster than the 3-4ns the original issue reported for .NET 5.0, indicating the regression has already been resolved by subsequent JIT/runtime optimizations.

All changes have been reverted. No code modifications remain in this PR.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Minor regression in System.Tests.Perf_Char.GetUnicodeCategory for non-ascii characters</issue_title>
<issue_description>I am now running an independent 3.1 vs 5.0 comparison and I've confirmed that it's actual regression introduced in 5.0.

The issue has been originally reported by a bot owned by @DrewScoggins in DrewScoggins/performance-2#574

Repro

git clone https://github.com/dotnet/performance.git
py .\performance\scripts\benchmarks_ci.py -f netcoreapp3.1 netcoreapp5.0 --filter 'System.Tests.Perf_Char.GetUnicodeCategory'

Details

System.Tests.Perf_Char.GetUnicodeCategory(c: '?')

Conclusion	Base	Diff	Base/Diff	Modality	Operating System	Bit	Processor Name	Base Runtime	Diff Runtime
Slower	5.82	7.89	0.74		Windows 10.0.18363.1016	Arm	Microsoft SQ1 3.0 GHz	.NET Core 3.1.6	5.0.100-rc.1.20413.9
Slower	3.15	4.08	0.77		Windows 10.0.18363.959	X64	Intel Xeon CPU E5-1650 v4 3.60GHz	.NET Core 3.1.6	5.0.100-rc.1.20404.3
Slower	3.03	4.10	0.74		Windows 10.0.18363.959	X64	Intel Xeon CPU E5-1650 v4 3.60GHz	.NET Core 3.1.6	5.0.100-rc.1.20418.3
Slower	3.40	4.80	0.71		Windows 10.0.19041.450	X64	Intel Core i7-5557U CPU 3.10GHz (Broadwell)	.NET Core 3.1.6	5.0.100-rc.1.20413.9
Slower	2.63	3.43	0.77		Windows 10.0.19042	X64	Intel Core i7-7700 CPU 3.60GHz (Kaby Lake)	.NET Core 3.1.6	5.0.100-rc.1.20418.3
Slower	1.86	4.54	0.41		Windows 10.0.18363.959	X86	Intel Xeon CPU E5-1650 v4 3.60GHz	.NET Core 3.1.6	5.0.100-rc.1.20420.2
Slower	2.27	5.28	0.43		Windows 10.0.19041.450	X86	Intel Core i7-5557U CPU 3.10GHz (Broadwell)	.NET Core 3.1.6	5.0.100-rc.1.20419.5
Slower	3.12	3.77	0.83		ubuntu 18.04	X64	Intel Xeon CPU E5-1650 v4 3.60GHz	.NET Core 3.1.6	5.0.100-rc.1.20403.23
Slower	3.52	5.28	0.67		macOS Mojave 10.14.5	X64	Intel Core i7-5557U CPU 3.10GHz (Broadwell)	.NET Core 3.1.6	5.0.100-rc.1.20404.2
Slower	2.01	3.01	0.67		ubuntu 18.04	X64	Intel Core i7-7700 CPU 3.60GHz (Kaby Lake)	.NET Core 3.1.6	5.0.100-rc.1.20418.3

No regressions for ascii chars:

System.Tests.Perf_Char.GetUnicodeCategory(c: '.')

Conclusion	Base	Diff	Base/Diff	Modality	Operating System	Bit	Processor Name	Base Runtime	Diff Runtime
Slower	0.66	2.31	0.29		Windows 10.0.18363.1016	Arm	Microsoft SQ1 3.0 GHz	.NET Core 3.1.6	5.0.100-rc.1.20413.9
Same	0.51	0.54	0.94		Windows 10.0.18363.959	X64	Intel Xeon CPU E5-1650 v4 3.60GHz	.NET Core 3.1.6	5.0.100-rc.1.20404.3
Same	0.52	0.55	0.95		Windows 10.0.18363.959	X64	Intel Xeon CPU E5-1650 v4 3.60GHz	.NET Core 3.1.6	5.0.100-rc.1.20418.3
Same	0.61	0.61	1.00		Windows 10.0.19041.450	X64	Intel Core i7-5557U CPU 3.10GHz (Broadwell)	.NET Core 3.1.6	5.0.100-rc.1.20413.9
Same	0.53	0.27	1.92		Windows 10.0.19042	X64	Intel Core i7-7700 CPU 3.60GHz (Kaby Lake)	.NET Core 3.1.6	5.0.100-rc.1.20418.3
Slower	0.43	0.76	0.56		Windows 10.0.18363.959	X86	Intel Xeon CPU E5-1650 v4 3.60GHz	.NET Core 3.1.6	5.0.100-rc.1.20420.2
Slower	0.50	0.87	0.57		Windows 10.0.19041.450	X86	Intel Core i7-5557U CPU 3.10GHz (Broadwell)	.NET Core 3.1.6	5.0.100-rc.1.20419.5
Same	0.47	0.52	0.92		ubuntu 18.04	X64	Intel Xeon CPU E5-1650 v4 3.60GHz	.NET Core 3.1.6	5.0.100-rc.1.20403.23
Same	0.58	0.59	0.98		macOS Mojave 10.14.5	X64	Intel Core i7-5557U CPU 3.10GHz (Broadwell)	.NET Core 3.1.6	5.0.100-rc.1.20404.2
Same	0.23	0.47	0.48	several?	ubuntu 18.04	X64	Intel Core i7-7700 CPU 3.60GHz (Kaby Lake)	.NET Core 3.1.6	5.0.100-rc.1.20418.3

System.Tests.Perf_Char.GetUnico...

• Fixes Minor regression in System.Tests.Perf_Char.GetUnicodeCategory for non-ascii characters #41107

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[jkotas]

@copilot Validate the performance improvement using performance-benchmark skill

[Copilot]

@copilot Validate the performance improvement using performance-benchmark skill

Running benchmark to validate the performance improvement:

@EgorBot -x64 -arm

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using System.Globalization;

BenchmarkSwitcher.FromAssembly(typeof(Bench).Assembly).Run(args);

[MemoryDiagnoser]
public class Bench
{
    private char _hebrewChar;
    private char _arabicChar;
    private char _chineseChar;
    private char _cyrillicChar;

    [GlobalSetup]
    public void Setup()
    {
        _hebrewChar = '\x05D0';   // Hebrew letter Aleph (from original issue)
        _arabicChar = '\x0623';   // Arabic letter Alef with Hamza above
        _chineseChar = '\u4E00';  // CJK Unified Ideograph
        _cyrillicChar = '\u0410'; // Cyrillic Capital Letter A
    }

    [Benchmark]
    public UnicodeCategory GetUnicodeCategory_Hebrew()
    {
        return char.GetUnicodeCategory(_hebrewChar);
    }

    [Benchmark]
    public UnicodeCategory GetUnicodeCategory_Arabic()
    {
        return char.GetUnicodeCategory(_arabicChar);
    }

    [Benchmark]
    public UnicodeCategory GetUnicodeCategory_Chinese()
    {
        return char.GetUnicodeCategory(_chineseChar);
    }

    [Benchmark]
    public UnicodeCategory GetUnicodeCategory_Cyrillic()
    {
        return char.GetUnicodeCategory(_cyrillicChar);
    }
}

This will compare the PR against the base branch to confirm the ~1-3ns improvement for non-ASCII characters.

[EgorBot]

@copilot, please review the benchmark results and logs at this URL: #124320

[jkotas]

@copilot Analyze why the fix has not produced the expected improvements.

[Copilot]

@copilot Analyze why the fix has not produced the expected improvements.

I analyzed why the initial fix didn't produce the expected improvement. The issue was that CharUnicodeInfo.GetUnicodeCategory(char) was missing the [MethodImpl(MethodImplOptions.AggressiveInlining)] attribute.

Root cause: While the fix correctly avoids the IsValidCodePoint validation check by calling the char overload, the JIT compiler may not have been inlining the char overload aggressively enough. This meant the call overhead could offset the benefit of skipping the validation.

Solution: Added [MethodImpl(MethodImplOptions.AggressiveInlining)] to CharUnicodeInfo.GetUnicodeCategory(char) to match the pattern used by similar methods in the same file (e.g., ToUpper(char), ToLower(char)).

This ensures that:

1. The char overload gets inlined into Char.GetUnicodeCategory(char)
2. The entire call chain collapses to just the core logic without validation overhead
3. The performance improvement becomes measurable

The change is in commit ca339b9. Please re-run the benchmark to verify the improvement.

[jkotas]

@copilot Run the above microbenchmark #124320 (comment) using performance-benchmark skill

[Copilot]

@copilot Run the above microbenchmark #124320 (comment) using performance-benchmark skill

Running the benchmark with the updated code (including AggressiveInlining):

@EgorBot -x64 -arm

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using System.Globalization;

BenchmarkSwitcher.FromAssembly(typeof(Bench).Assembly).Run(args);

[MemoryDiagnoser]
public class Bench
{
    private char _hebrewChar;
    private char _arabicChar;
    private char _chineseChar;
    private char _cyrillicChar;

    [GlobalSetup]
    public void Setup()
    {
        _hebrewChar = '\x05D0';   // Hebrew letter Aleph (from original issue)
        _arabicChar = '\x0623';   // Arabic letter Alef with Hamza above
        _chineseChar = '\u4E00';  // CJK Unified Ideograph
        _cyrillicChar = '\u0410'; // Cyrillic Capital Letter A
    }

    [Benchmark]
    public UnicodeCategory GetUnicodeCategory_Hebrew()
    {
        return char.GetUnicodeCategory(_hebrewChar);
    }

    [Benchmark]
    public UnicodeCategory GetUnicodeCategory_Arabic()
    {
        return char.GetUnicodeCategory(_arabicChar);
    }

    [Benchmark]
    public UnicodeCategory GetUnicodeCategory_Chinese()
    {
        return char.GetUnicodeCategory(_chineseChar);
    }

    [Benchmark]
    public UnicodeCategory GetUnicodeCategory_Cyrillic()
    {
        return char.GetUnicodeCategory(_cyrillicChar);
    }
}

This will verify the ~1-3ns improvement now that both fixes are in place (char overload + AggressiveInlining).

[EgorBot]

@copilot, please review the benchmark results and logs at this URL: #124320

[stephentoub]

@copilot, please review the benchmark results and logs at this URL: #124320

@EgorBo, what configuration do we need to do for @copilot to recognize / respond to your bot account?

[stephentoub]

Also, @EgorBo, it looks like the bot is including the wrong link in the comment it posts.

[Copilot]

@copilot, please review the benchmark results and logs at this URL: #124320

@EgorBo, what configuration do we need to do for @copilot to recognize / respond to you...

I reviewed the benchmark results from both EgorBot runs (#612, #613).

Both runs show the changes caused a regression, not an improvement:

x64 (AMD EPYC 9V74): PR is 1.88x slower across all characters:

Method	Main	PR	Ratio
Hebrew	0.29 ns	0.55 ns	1.88
Arabic	0.29 ns	0.55 ns	1.89
Chinese	0.29 ns	0.55 ns	1.88
Cyrillic	0.29 ns	0.55 ns	1.88

ARM64 (Neoverse-N2): Neutral (ratio ~0.98-1.02).

Adding AggressiveInlining made no difference — both runs produced identical x64 results.

The JIT is already optimizing the (int)c path extremely well — the IsValidCodePoint check is trivially eliminated for char-width values, and the resulting code is more efficient than going through the char overload. Main's ~0.29ns is already ~10x faster than the 3-4ns the original issue reported for .NET 5.0.

I've reverted all changes in 8a07341. The original regression from the issue appears to have already been resolved by subsequent JIT/runtime optimizations.