Работа со строками. Строковые функции

Добрый день, коллеги. В этом посте мне хочется рассказать вам про строки в .NET и, что немаловажно, как же оптимизировать код для работы с ними.

В большинстве книг пишут, что при слиянии (конкатенации) строк надо всегда использовать StringBuilder. На практике же видно, что в общем случае простое суммирование двух строк работает намного быстрее. Забегая вперед хочу сказать, что в первом случае львиная доля времени будет затрачена на создание экземпляра класса StringBuilder и весь этот незамысловатый код сработает медленнее.

Вопрос заключается в том, что же действительно происходит при работе со строками? Как следует поступать программисту, чтобы простейшие строковые операции не стали ботлнеком (англ. bottleneck - горлышко бутылки - узкое место программы)?

Тут я приведу некое подобие мануала, по работе со строками, которое, надеюсь, будет одинаково полезно, как новичкам, так и "людям со стажем".

Лучшее описание данной проблемы я нашел в книге Patterns&Practices от Microsoft в главе "Improving Managed Code Performance" (увеличение производительности кода). Тут я приведу свой перевод этого текста.

Для представления строк в среде исполнения .NET используется класс System.String. В связи с неизменяемой природой строк, множественная манипуляция ими может существенно сказаться на производительности приложения в целом. Это значит, что при любом изменении строки в своей программе создается новый экземпляр System.String, старый отбрасывается и в дальнейшем подвергается сборщику мусора. Также стоит отметить, что так как System.String является ссылочным типом, то память под содержимое строки выделяется в управляемой куче, а следовательно для удаления строк необходимо(!) использовать сборку мусора.

Здесь обобщены рекомендации по использованию строк:
- Избегайте неэффективной конкатенации строк
- Используйте + когда Вы знаете количество объединяемых строк
- Используйте StringBuilder, когда количество объединяемых строк неизвестно
- Используйте StringBuilder как накопитель строк
- Используйте метод String.Compare для нечувствительного в регистру сравнения строк

1) Избегайте неэффективной конкатенации строк

Каждый раз при изменении строки создается её новый экземпляр, а старый подвергается сборщику мусора. Таким образом эти множественные выделения памяти являются излишними.

- Если Вы объединяете строковые литералы, то компилятор объединит их на этапе компиляции:
- Если Вы объединяете нелитеральные строки, CLR будет объединять их в процессе выполнения, так что оператор + будет создавать множество строковых объектов в упраляемой куче.
- Используйте StringBuilder, когда Вам требуется комплексная обработка или множественное объединение строк:
2) Используйте + когда Вы знаете количество объединяемых строк

Если Вы знаете количество объединяемых строк, то хотите их объединить за раз, то предпочтительнее использование оператора +.
Вообще говоря, для объединения строк в одном выражении требуется только один вызов String.Concat. В результате не будет создано множество временных строк (для хранения результатов промежуточных объединений строк).

Важно! Не используйте оператор + для объединения строк в циклах. Вместо этого используйте StringBuilder

3) Используйте StringBuilder, когда количество объединяемых строк неизвестно

Если Вы не знаете количество объединяемых строк, например тогда, когда объединение происходит в цикле, или Вы строите длинные динамические SQL запросы, то используйте класс StringBuilder как показано ниже
По умолчанию длина буфера для хранения строк у StringBuilder равна 16. Строки, длина которых меньше начального размера этого буфера хранятся внутри экземпляра StringBuilder.
Начальный размер буфера StringBuilder можно установить при использовании перегруженного конструктора:
Далее Вы можете продолжать объединять строки без дополнительных выделений памяти до тех пор пока не будет превышен размер буфера. Следовательно, StringBuilder более эффективен, чем String для операций конкатенации. При дальнейшем объединении строк StringBuilder будет при необходимости удваивать размер своего внутреннего буфера.

Так что, если вы начали со стартового размера буфера в 16 байт, то при его переполнении выделится память под новый - размера 32, старая строка будет скопирована из старого буфера в новый, а сам старый буфер уже сможет быть удален сборщиком мусора.

Важно!Лучше всегда указывать размер начального буфера во избежание потери производительности при новых выделениях памяти. Лучшим способом нахождения оптимального значения размера буфера является использование профилировщиков среды CLR

4) Используйте StringBuilder как накопитель строк

Вы можете использовать StringBuilder как накопитель строк или многоразовый буфер. Это поможет избежать затрат на множественное выделение памяти при вызовах присоединений строк.

- Объединение строк. Вы всегда должны использовать следующую конструкцию для объединения строк через StringBuilder
Но, никогда не используйте следующее выражение:
потому что, не требуется создавать отдельную временную переменную для хранения str1 + str2 в процессе их объединения.

- Объединение строк-результатов функций:
В предыдущем примере после каждого выполнения функции выделяется память для временной строки-результата, а, следовательно, более предпочтительным оказывается вариант передачи StringBuilder как параметра в сами методы:
Таким образом sb.Append будет вызван уже внутри тела функции и не будет необходимости создавать промежуточные буферы

5) Используйте метод String.Compare для нечувствительного в регистру сравнения строк

Аккуратно посмотрите на то, как Вы производите безразличные к регистру букв операции сравнения строк. Избегайте использования ToLower, так как это приводит к созданию временных объектов как показано в этом примере:
Наиболее эффективный способ таких сравнений - использование метода Compare:
Надеюсь данный обзор поможет Вам писать более производительный код в среде CLR.

Тут не могу не привести еще две языковые конструкции с использованием литерального модификатора в C#. Они не влияют на производительность, но также скорее всего помогут Вам в дальнейшем:

1) @ для объединения литералов:
- тут не используется раздражающая конструкция 2) @ для спецсимволов:
- это также может использоваться для составления регулярных выражений или SQL запросов.

Спасибо за внимание!

105