System.Text.Encoding.Unicode Performance Slower than .NETFramework2.0

[HelloKitty]

Not sure if this is the correct place but after profiling a library I'm working on I found that System.Text.Encoding.Unicode.GetString was 10x slower in .NETCore/>=.NETFramework4.0. However I found that this was not the case in <=.NETFramework3.5 on my machine.

Maybe the performance degregadation could be attributed to something else but it was equivalent benchmarking code ran on .NET Core and >=.NETFramework4.0 and .NETFramework2.0-3.5. The .NETFramework 2.0 was faster for only the System.Text.Encoding.Unicode.GetString which seemed very peculiar. Everything else in the benchmark ran as expected.

[danmoseley]

@HelloKitty could you share a code snippet that reproes the slowdown?

[HelloKitty]

I created a quick repro. This doesn't seem to show the same significant slowdown but it shows about a 1.5x slowdown. I'm finding it difficult to repro in isolation the 10x slowdown I encountered in a benchmark I use for one of my library using exactly the same code.

[redacted repro]

[HelloKitty]

Ahhh found how to repro it. The issue is it appears to scale by string length. It degrades significantly the longer the string gets as far as I can tell while the .NETFramework2.0 version seems to scale much better,

using System;
using System.Diagnostics;
using System.Text;

namespace StringSlowRepro
{
	class Program
	{
		static void Main(string[] args)
		{
			string testString = @"inADUInsafd8hasdf98hdsf89h*(HASD*(HS*(DFbns98dbhsd98dbdgf98bdguisbng98sdng98nSFN*()S(*nSF98nsf89ns89fn*(*(NAMIOPSDOPDSFOP<DX<O";
			byte[] bytes = Encoding.Unicode.GetBytes(testString);
			Stopwatch watch = new Stopwatch();

			watch.Start();
			for(int i = 0; i < 10000000; i++)
				Encoding.Unicode.GetString(bytes);
			watch.Stop();

			Console.WriteLine($"10000000 Iterations: {watch.Elapsed}");
			Console.ReadKey();
		}
	}
}

[joshua-light]

Hi!

I've tried to reproduce the problem, but the only strange thing I've found is that there is some small performance gains in .NET from 2.0 to 3.0, and then in 4.5 and 4.6. But 4.0 looks different. It has over 4x slower performance.

Here is screenshot:

And the program is like that:

static void Main(string[] args)
{
    Profile(1000);
    Profile(10000);
    Profile(100000);
    Profile(1000000);
    Profile(10000000);

    Console.ReadKey();
}

static void Profile(int iterations)
{
    const string testString = @"inADUInsafd8hasdf98hdsf89h*(HASD*(HS*(DFbns98dbhsd98dbdgf98bdguisbng98sdng98nSFN*()S(*nSF98nsf89ns89fn*(*(NAMIOPSDOPDSFOP<DX<O";
    var bytes = Encoding.Unicode.GetBytes(testString);

    var watch = Stopwatch.StartNew();
    for (int i = 0; i < iterations; i++)
        Encoding.Unicode.GetString(bytes);
    watch.Stop();

    Console.WriteLine("{0} Iterations: {1}", iterations, watch.ElapsedMilliseconds + "ms.");
}

This is ofcourse not the best profile sessions, and maybe someone could reproduce the same thing in more technically correct way.

[Wraith2]

I started looking into this and tried to replicate using benchmarkdotnet. Unfortunately I can't find a way to make benchmarks run with previous clr versions (tried ClrRuntime() with the various options I know I have installed, didn't find them).

However what I have found is a performance difference between x86 and x64 of 1:5 on from netfx4 and core which seems like a very big difference. I wonder if this is expected/known and if it is worth investigating further?

Gist is here

BenchmarkDotNet=v0.10.14, OS=Windows 10.0.17134
Intel Core i5-7600K CPU 3.80GHz (Kaby Lake), 1 CPU, 4 logical and 4 physical cores
.NET Core SDK=2.1.201
  [Host] : .NET Core 2.0.7 (CoreCLR 4.6.26328.01, CoreFX 4.6.26403.03), 64bit RyuJIT
  clr64  : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.7.3101.0
  clr86  : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 32bit LegacyJIT-v4.7.3101.0
  core64 : .NET Core 2.0.7 (CoreCLR 4.6.26328.01, CoreFX 4.6.26403.03), 64bit RyuJIT
  core86 : .NET Core 2.0.6 (CoreCLR 4.6.26212.01, CoreFX 4.6.26212.01), 32bit RyuJIT

Method	Job	Platform	Runtime	Toolchain	IsBaseline	iterations	Scaled
GetString	clr64	X64	Clr	Default	Default	10	0.73
GetString	clr86	X86	Clr	Default	Default	10	0.14
GetString	core64	X64	Core	64 bit cli	True	10	1.00
GetString	core86	X86	Core	32 bit cli	Default	10	0.19
GetString	clr64	X64	Clr	Default	Default	1000	0.74
GetString	clr86	X86	Clr	Default	Default	1000	0.14
GetString	core64	X64	Core	64 bit cli	True	1000	1.00
GetString	core86	X86	Core	32 bit cli	Default	1000	0.20
GetString	clr64	X64	Clr	Default	Default	100000	0.73
GetString	clr86	X86	Clr	Default	Default	100000	0.14
GetString	core64	X64	Core	64 bit cli	True	100000	1.00
GetString	core86	X86	Core	32 bit cli	Default	100000	0.19

[danmoseley]

@Wraith2 that is interesting. Any chance you could use 2.1 RC or later to check it wasn't fixed since?

@tarekgh that is a big difference.

[Wraith2]

results.zip

Sorry, should have gone with 2.1rc to start with. Unfortunately the results are almost identical.

BenchmarkDotNet=v0.10.14, OS=Windows 10.0.17134
Intel Core i5-7600K CPU 3.80GHz (Kaby Lake), 1 CPU, 4 logical and 4 physical cores
.NET Core SDK=2.1.300-rc1-008673
  [Host] : .NET Core 2.1.0-rc1 (CoreCLR 4.6.26426.02, CoreFX 4.6.26426.04), 64bit RyuJIT
  clr64  : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.7.3101.0
  clr86  : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 32bit LegacyJIT-v4.7.3101.0
  core64 : .NET Core 2.1.0-rc1 (CoreCLR 4.6.26426.02, CoreFX 4.6.26426.04), 64bit RyuJIT
  core86 : .NET Core 2.1.0-rc1 (CoreCLR 4.6.26426.02, CoreFX 4.6.26426.04), 32bit RyuJIT

Method	Job	Platform	Runtime	Toolchain	IsBaseline	iterations	Scaled
GetString	clr64	X64	Clr	Default	Default	10	0.74
GetString	clr86	X86	Clr	Default	Default	10	0.14
GetString	core64	X64	Core	64 bit cli	True	10	1.00
GetString	core86	X86	Core	32 bit cli	Default	10	0.18
GetString	clr64	X64	Clr	Default	Default	1000	0.76
GetString	clr86	X86	Clr	Default	Default	1000	0.14
GetString	core64	X64	Core	64 bit cli	True	1000	1.00
GetString	core86	X86	Core	32 bit cli	Default	1000	0.18
GetString	clr64	X64	Clr	Default	Default	100000	0.76
GetString	clr86	X86	Clr	Default	Default	100000	0.14
GetString	core64	X64	Core	64 bit cli	True	100000	1.00
GetString	core86	X86	Core	32 bit cli	Default	100000	0.18

I added in the benchmarkdotnet assembly diagnose to see if there was anything strikingly different about the methods. There doesn't seem to be to my untrained eyes but I did notice that the x64 version seems to use an al register which I thought was an old 16 bit one. I'll attach the dumps so someone with experience can look and see if there is anything interesting there or they're irrelevant.

[jkotas]

performance difference between x86 and x64 of 1:5

The implementation is using 64-bit integers to implement the fast path: https://github.com/dotnet/coreclr/blob/master/src/System.Private.CoreLib/shared/System/Text/UnicodeEncoding.cs#L1474. It works great on 64-bit platforms, but not so well on 32-bit platforms. To reduce the performance gap, this may be need to be ifdefed for 32-bit vs. 64-bit, like other similar places in CoreLib.

[benaadams]

But the 32bit version is faster than the 64bit version; which is the curious thing

[jkotas]

I see - that one is an issue with ifdefed alignment checks before going into the fast loop: https://github.com/dotnet/coreclr/blob/master/src/System.Private.CoreLib/shared/System/Text/UnicodeEncoding.cs#L1459 . The check is always false in the micro-benchmark on x64, so the fast loop is never entered. If the micro-benchmark is modified to:

    var watch = Stopwatch.StartNew();
    for (int i = 0; i < iterations; i++)
        Encoding.Unicode.GetString(bytes, 4, bytes.Length-4);
    watch.Stop();

the alignment check succeeds and the performance of the two becomes a lot more similar.

[Wraith2]

I did some further investigation and the alignment is important but not quite in the way you've stated I don't think. A very short string used as a source of bytes does have little difference between 32 and 64 but as the input length is increased the difference grows until it reaches what the benchmarks showed.

I took the code for the various bits of infrastructure needed for the method into a separate project and recreated the test as best I could but the performance of my 64 bit version always seemed to be equal to the 32 bit version, which was very confusing. The one thing I hadn't been able to replicate was the internal EECall backed FastAllocateStirng so I'd just newed up a char[] and, this was the difference.

The internals of the native StringObject class have a dword followed by the char*, this means that unless it is packed to 64 alignment on 64 bit systems (which I can't see) the first two chars in the string will never be aligned and will drop into the slow path for surrogate checking. Once through that on the first two chars it will drop into the fast loop and as long as no surrogates are used this will allow it to continue through the fast loop. Those first two unaligned chars seem to be what makes all the difference and the apparent overhead of dealing with them seems to become a large weight in the performance profile of the method as input length increases.

If I'm right about some of this then the apparently issue is pretty deep and has been present for quite some time so I don't think it's likely to get a "fix" anytime soon. Obvious avenues of approach are changing the string layout on 64 bit (unlikely) or renting a char[] from a pool and using that as the target then newing up the string from that (feels like a lot of intermediate code).

The investigative project is here if anyone wants to play along.