4>FW 3.5: Int (1000000) 100000000 op / 0,872 sec = 114699379
4>FW 4.0: Int (1000000) 100000000 op / 0,990 sec = 101008734
4>Core31: Int (1000000) 100000000 op / 0,893 sec = 111996104
4>

Стоит отметить, что на .Net Core 2.1 результат аналогичен FW 4+, что демонстрирует преемственность.

Обновил VS 2019 до версии 16.5.5, сбилдил и запустил этот "тест" под Core 3.1 — результат аналогичен Core 2.1

FW3.5 : String (100000) 1000000 op / 1,998 sec = 500451
FW4.0 : String (100000) 1000000 op / 5,480 sec = 182481

т.е. получаю регресс производительности в 2.7 раза (!)

На Core 3 поиск Int в List стал примерно в 6 раз быстрее, а поиск строк — в 1.4 раза. В Core JIT научился в некоторых ситуациях девирутализировать виртуальные методы, т.е. они вызываются напрямую. Более того, такие методы могут быть заинлайнены. В данном случае девиртуализируется метод EqualityComparer.Default.Equals, который используется для сравнения элементов. В случае с Int всё сводится к вызову Int32.Equals, который к тому же инлайнится. В итоге получившийся код по эффективности близок к прямому сравнению двух Int.

Кстати, раньше я всегда думал, что метод Contains внутри вызывает IndexOf, но оказалось, что это верно только для Core. В полном фреймворке это разные методы, и работают они с разной скоростью.

Интересно почему тогда string.Contains дает аналогичные результаты на 3.5 и 4+, может локале-ориентированный компаратор сильно "фонит":
c += arr.Count(s => s.Contains(key));


3.5: String (100000) 1000000 op / 0,248 sec = 4030540
4.0: String (100000) 1000000 op / 0,237 sec = 4205221


Также аналогичные результаты можно получить, если явно в качестве компаратора указать StringComparison.Ordinal:

c += arr.Count(s => s.IndexOf(key, StringComparison.Ordinal) > -1);


3.5: String (100000) 1000000 op / 0,246 sec = 4053168
4.0: String (100000) 1000000 op / 0,239 sec = 4181658

 public int List_Contains()
    {
        int count = 0;
        List<T> collection = _list;
        T[] array = _lookupValues;

        for (int i = 0; i < array.Length; i++)
        {
            if (collection.Contains(array[i]))
                count++;
        }

        return count;
    }

На Core 3 поиск Int в List стал примерно в 6 раз быстрее, а поиск строк — в 1.4 раза. В Core JIT научился в некоторых ситуациях девирутализировать виртуальные методы, т.е. они вызываются напрямую. Более того, такие методы могут быть заинлайнены. В данном случае девиртуализируется метод EqualityComparer.Default.Equals, который используется для сравнения элементов. В случае с Int всё сводится к вызову Int32.Equals, который к тому же инлайнится. В итоге получившийся код по эффективности близок к прямому сравнению двух Int.

Кстати, раньше я всегда думал, что метод Contains внутри вызывает IndexOf, но оказалось, что это верно только для Core. В полном фреймворке это разные методы, и работают они с разной скоростью.

using System;
using System.Collections.Generic;

class Program
{
    static void Main(string[] args)
    {
        StrBench(1000000);
    }

    static void StrBench(int arrSize)
    {
        const int cnt = 10;

        List<string> arr = new List<string>(arrSize);
        for (int j = 0; j < arrSize; j++)
            arr.Add(string.Format("{0}{1}{2}", new string('Ё', 100), BuildKey(j), new string('x', 100)));

        string key = arr[arr.Count - 1];
        int c = 0;

        var sw = new System.Diagnostics.Stopwatch();
        sw.Start();

        for (int i = 0; i < cnt; i++)
            c += arr.IndexOf(key);

        double ts = sw.Elapsed.TotalSeconds;
        ulong total = (ulong)arrSize * (ulong)cnt;

        Console.WriteLine("String ({3}) {0} op / {1:0.000} sec = {2:0}", total, ts, total / ts, arrSize);
    }

    static string BuildKey(int i)
    {
        return i.ToString().PadLeft(10, '0');
    }
}

using System;
using System.Collections.Generic;

class Program
{
    static void Main(string[] args)
    {
        IntBench(1000000);
    }

    static void IntBench(int arrSize)
    {
        const int cnt = 1000;

        List<int> arr = new List<int>(arrSize);
        for (int j = 0; j < arrSize; j++)
            arr.Add(j);

        int key = arrSize - 1;
        int c = 0;

        var sw = new System.Diagnostics.Stopwatch();
        sw.Start();

        for (int i = 0; i < cnt; i++)
            c += arr.IndexOf(key);

        double ts = sw.Elapsed.TotalSeconds;
        ulong total = (ulong)arrSize * (ulong)cnt;

        Console.WriteLine("String ({3}) {0} op / {1:0.000} sec = {2:0}", total, ts, total / ts, arrSize);
    }
}

В ожидании следующего основного выпуска .NET 5 мы продолжим объединять .NET в единую платформу, включив нашу модель приложения для мобильных устройств .NET (Xamarin) в .NET 5. .NET 5 будет включать ASP.NET Core, Entity Framework Core, WinForms, WPF, Xamarin и ML.NET. Впервые вся платформа будет использовать унифицированный BCL (библиотеки базовых классов) для всех моделей приложений. Наличие версии 5, которая выше, чем у .NET Core и .NET Framework, также дает понять, что .NET 5 — это будущее .NET, единой унифицированной платформы для создания приложений любого типа.

Пакет обеспечения совместимости Windows основан на .NET Standard и обеспечивает доступ к таким технологиям, которые доступны только в Windows. Это особенно полезно для клиентов, которые хотят перейти на .NET Core, но по меньшей мере на первом этапе планируют оставаться в Windows. В этом сценарии возможность использования технологий, предназначенных только для Windows, устраняет препятствия для миграции.