Can you verify that Array.Empty is faster than the private implementation? I recall measuring and surprisingly the private implementation was faster despite the code being identical - presumably the assembly containing the generic code has (had?) some impact on code generation.

IIRC, the private code was necessary to keep Windows PowerShell running with supported versions of the desktop CLR, but I measured anyway because I was curious.

Can you verify that Array.Empty is faster than the private implementation?

@lzybkr I believe that make sense only after we move to .Net Core 3.0 - the new runtime has huge performance improvements. Although now I could do a simple test using BenchmarkDotNet.

It seems performance of both comparable with .Net Core 3.0 Preview2 taking in account measure errors.

BenchmarkDotNet=v0.11.4, OS=Windows 10.0.17763.253 (1809/October2018Update/Redstone5)
Intel Core i5-2410M CPU 2.30GHz (Sandy Bridge), 1 CPU, 4 logical and 2 physical cores
.NET Core SDK=3.0.100-preview-010184
  [Host]      : .NET Core 3.0.0-preview-27324-5 (CoreCLR 4.6.27322.0, CoreFX 4.7.19.7311), 64bit RyuJIT
  TC Disabled : .NET Core 3.0.0-preview-27324-5 (CoreCLR 4.6.27322.0, CoreFX 4.7.19.7311), 64bit RyuJIT
  TC Enabled  : .NET Core 3.0.0-preview-27324-5 (CoreCLR 4.6.27322.0, CoreFX 4.7.19.7311), 64bit RyuJIT

Runtime=Core  Toolchain=.NET Core 3.0  

@iSazonov - did your benchmark use types defined in System.Management.Automation? I seem to recall that was where I saw a difference.

The test code is:

        [Benchmark(Baseline = true)]
        public string[] CoreFXEmptyArray()
        {
            return Array.Empty<string>();
        }

        [Benchmark]
        public string[] CustomEmptyArray()
        {
            return EmptyArray<string>();
        }

String and object - these are most common.

Do try types in other assemblies. The code is minimal, and if there is a performance difference, I see no reason for the change.

Today I can not compile SMA with .Net Core 3.0 and get types from it.

I recall measuring and surprisingly the private implementation was faster despite the code being identical - presumably the assembly containing the generic code has (had?) some impact on code generation.

What runtime you measure with? I guess .Net FrameWork? .Net Core 3.0 has a lot of new optimizations. I saw that 3.0 more faster 2.1 while working on Simple Case Folding.
Previously the custom code (EmptyArray) could be faster because of AggresiveInlining attribute. Both Framework and Core haven't this attribute but 3.0 uses TC and new code gen.

In my measure 3.0 generate identical code for both if TC=0 and different code if TC=1 - the second is so fast that error > value (I could get better result). Disasm file attached

System.Text.CaseFolding.IntroBenchmarkBaseline-asm.raw.html.zip

I most likely measured it with 4.6.2.

I don't know how important SMA is, you could try using a type defined in you benchmark assembly to see if that is different than object or string.

BenchmarkDotNet=v0.11.4, OS=Windows 10.0.17763.253 (1809/October2018Update/Redstone5)
Intel Core i5-2410M CPU 2.30GHz (Sandy Bridge), 1 CPU, 4 logical and 2 physical cores
.NET Core SDK=3.0.100-preview-010184
  [Host]      : .NET Core 3.0.0-preview-27324-5 (CoreCLR 4.6.27322.0, CoreFX 4.7.19.7311), 64bit RyuJIT
  TC Disabled : .NET Core 3.0.0-preview-27324-5 (CoreCLR 4.6.27322.0, CoreFX 4.7.19.7311), 64bit RyuJIT
  TC Enabled  : .NET Core 3.0.0-preview-27324-5 (CoreCLR 4.6.27322.0, CoreFX 4.7.19.7311), 64bit RyuJIT

Runtime=Core  Toolchain=.NET Core 3.0  

The same results. For TC=0 we have reliable results and approximately equal values ​​within the error. For TC=1 error exceeds the value - all is very fast.

I most likely measured it with 4.6.2.

This suggests that this measures should be repeated for .Net Core (for each version with which we release?).

Thanks for testing - I don't have any concerns with the change.