String.Contains () быстрее, чем String.IndexOf ()?

У меня есть строковый буфер размером около 2000 символов, и мне нужно проверить буфер, содержит ли он конкретную строку.
Выполняет проверку в веб-приложении ASP.NET 2.0 для каждого веб-запроса.

Кто-нибудь знает, работает ли метод String.Contains лучше, чем метод String.IndexOf ?

    // 2000 characters in s1, search token in s2
    string s1 = "Many characters. The quick brown fox jumps over the lazy dog"; 
    string s2 = "fox";
    bool b;
    b = s1.Contains(s2);
    int i;
    i = s1.IndexOf(s2);

Забавный факт

Containsзвонки IndexOf:

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

Какие вызовы CompareInfo.IndexOf, которые в конечном итоге используют реализацию CLR.

Если вы хотите увидеть, как сравниваются строки в CLR, это покажет вам (ищите CaseInsensitiveCompHelper ).

IndexOf(string)не имеет параметров и Contains()использует порядковое сравнение (побайтовое сравнение вместо попытки интеллектуального сравнения, например, e с é).

Так IndexOf будет немного быстрее (теоретически), поскольку он IndexOfпереходит прямо к поиску строки с использованием FindNLSString из kernel32.dll (мощность отражателя!).

Обновлено для .NET 4.0 - IndexOf больше не использует порядковое сравнение, поэтому Contains может быть быстрее. См. Комментарий ниже.

Наверное, это вообще не будет иметь значения. Прочтите этот пост о Coding Horror;): http://www.codinghorror.com/blog/archives/001218.html

Contains (s2) во много раз (на моем компьютере в 10 раз) быстрее, чем IndexOf (s2), потому что Contains использует StringComparison.Ordinal, который быстрее, чем поиск с учетом языка и региональных параметров, который выполняет IndexOf по умолчанию (но это может измениться в .net 4.0 http: //davesbox.com/archive/2008/11/12/breaking-changes-to-the-string-class.aspx ).

Contains имеет точно такую ​​же производительность, что и IndexOf (s2, StringComparison.Ordinal)> = 0 в моих тестах, но он короче и проясняет ваше намерение.

Я использую реальный случай (в отличие от синтетического теста)

 if("=,<=,=>,<>,<,>,!=,==,".IndexOf(tmps)>=0) {

против

 if("=,<=,=>,<>,<,>,!=,==,".Contains(tmps)) {

Это жизненно важная часть моей системы, и она выполняется 131 953 раза (спасибо DotTrace).

Как ни шокирующе удивил , результат оказался противоположным ожидаемому.

• Индекс 533 мс.
• Содержит 266 мс.

: - /

net framework 4.0 (обновлено 13.02.2012)

Используя Reflector, вы можете увидеть, что Contains реализуется с помощью IndexOf. Вот реализация.

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

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

Если вы действительно хотите оптимизировать свой код на микроуровне, лучший подход - это тестирование.

В инфраструктуре .net есть отличная реализация секундомера - System.Diagnostics.Stopwatch.

Из небольшого чтения кажется, что под капотом метод String.Contains просто вызывает String.IndexOf. Разница в том, что String.Contains возвращает логическое значение, а String.IndexOf возвращает целое число с (-1), представляющим, что подстрока не была найдена.

Я бы посоветовал написать небольшой тест с примерно 100 000 итераций и убедиться в этом сам. Если бы я догадался, я бы сказал, что IndexOf может быть немного быстрее, но, как я уже сказал, это всего лишь предположение.

Джефф Этвуд опубликовал в своем блоге хорошую статью о струнах . Это больше о конкатенации, но, тем не менее, может быть полезно.

Так же, как обновление этого, я провел некоторое тестирование и предоставил вам довольно большую входную строку, тогда параллельное Regex - это самый быстрый метод C #, который я нашел (при условии, что у вас есть более одного ядра, как мне кажется)

Например, получение общего количества совпадений -

needles.AsParallel ( ).Sum ( l => Regex.IsMatch ( haystack , Regex.Escape ( l ) ) ? 1 : 0 );

Надеюсь это поможет!

Используйте библиотеку тестов, например, в недавнем набеге Джона Скита, чтобы измерить ее.

Пусть покупатель будет бдителен

Как и все вопросы (микро) производительности, это зависит от версий программного обеспечения, которые вы используете, деталей проверяемых данных и кода, связанного с вызовом.

Как и все вопросы (микро) производительности, первым шагом должно быть получение работающей версии, которую легко поддерживать. Затем к измеренным узким местам можно применить сравнительный анализ, профилирование и настройку вместо предположений.

Для тех, кто все еще читает это, indexOf (), вероятно, будет лучше работать в большинстве корпоративных систем, поскольку contains () несовместим с IE!