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);
    }
}

using System;
using System.Linq;
using System.Collections.Generic;

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

    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('x', 100), BuildKey(j), new string('x', 100)));

        string key = BuildKey(arrSize - 1);
        int c = 0;

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

        for (int i = 0; i < cnt; i++)
            c += arr.Count(s => s.IndexOf(key) > -1);

        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');
    }
}

Железка: Core i5-6500 (3.2-3.6 ГГц), 16 Gb (DDR4 1066Мгц) под Win10 x64

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

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

c += arr.Count(s => s.Contains(key));

FW3.5 : String (100000) 1000000 op / 0,243 sec = 4110945
FW4.0 : String (100000) 1000000 op / 0,249 sec = 4016593

c += arr.AsParallel().Count(s => s.IndexOf(key) > -1);

FW4.0 : String (100000) 1000000 op / 1,505 sec = 664617

Умозаключения и прочая философия

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

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

Remarks

This method performs an ordinal (case-sensitive and culture-insensitive) comparison.

public bool Contains( string value ) {
    return ( IndexOf(value, StringComparison.Ordinal) >=0 );
}

Начиная с .NET Framework 2.0 с пакетом обновления 1 (SP1) и до .NET Framework 4, каждая версия .NET Framework включает таблицы, которые содержат веса сортировки и данные по нормализации строк и основаны на конкретной версии Unicode. В .NET Framework 4.5 наличие этих таблиц зависит от операционной системы:
В Windows 7 и предыдущих версиях операционной системы Windows таблицы продолжают использоваться для сравнения и упорядочивания строк.
В Windows 8 .NET Framework делегирует операции сравнения строк и упорядочения операционной системе.
Следовательно, результат сравнения строк может зависеть не только от версии .NET Framework, но и от версии операционной системы, как показано в следующей таблице. Обратите внимание, что этот список поддерживаемых версий Unicode применяется только для сравнения и сортировки символов; это не относится к классификации символов Юникода по категориям.

VD>Тем более странно, что ты разницу в работе одной функции проецируешь на весь .Net 4.0.

В данном случае код местами переписан, проблемы нет (плюс профит от распараллеливания средствами LINQ), но беспокоит сам факт, что пришлось это делать.

Сортировка и сравнение строк в .NET Framework

Начиная с .NET Framework 2.0 с пакетом обновления 1 (SP1) и до .NET Framework 4, каждая версия .NET Framework включает таблицы, которые содержат веса сортировки и данные по нормализации строк и основаны на конкретной версии Unicode. В .NET Framework 4.5 наличие этих таблиц зависит от операционной системы:
В Windows 7 и предыдущих версиях операционной системы Windows таблицы продолжают использоваться для сравнения и упорядочивания строк.
В Windows 8 .NET Framework делегирует операции сравнения строк и упорядочения операционной системе.
Следовательно, результат сравнения строк может зависеть не только от версии .NET Framework, но и от версии операционной системы, как показано в следующей таблице. Обратите внимание, что этот список поддерживаемых версий Unicode применяется только для сравнения и сортировки символов; это не относится к классификации символов Юникода по категориям.

public int IndexOf(string value)
{
    return CultureInfo.CurrentCulture.CompareInfo.IndexOf(this, value);
}

using System;
using System.Linq;
using System.Collections.Generic;

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

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

        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.Count(s => s == key);

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

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

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

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. В полном фреймворке это разные методы, и работают они с разной скоростью.

В ожидании следующего основного выпуска .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, устраняет препятствия для миграции.