C# 6 трюки с производительностью

Эта статья расскажет о нескольких мини-хитростях, связанных с .NET, для улучшения производительности вашего кода. На первый взгляд эти трюки могут показаться ненужными, но они принесут абсолютный прирост производительности. Все коды бенчмарков можно найти в репозитории github здесь. Готовы раздвинуть границы?

Как вы называете многомерный массив, очень важно

Предположим, у нас есть двумерный массив размером 1000x1000. И вам нужно проверить один за другим весь массив. Вы используете array[i][j]или array[j][i] при вызове элемента? Или вы говорите «какое это имеет значение?» Давайте объясним.

Выше приведены две части тестового кода C#. Ничего страшного на первый взгляд нет. Но результаты тестов этого не показывают. Производительность увеличилась почти на 60%. Также существует разный размер выделения. Причина в том, что .NET ходит по памяти при вызове элемента из массива. Таким образом, чем больше промежутков между двумя вызовами, тем больше снижение производительности. .NET действительно заботится о локальности памяти.

Какая из них лучше? for, foreach и `List ForEach` циклов

Мы часто используем эти циклические структуры. Но мы не рассматриваем с точки зрения производительности. В рамках этого заголовка я не буду рассказывать о том, из чего они. Просто я хочу, чтобы вы увидели разницу в производительности.

Выше приведены две части тестового кода C#. Это просто вызов элемента списка. В результатах тестов лучше всего работает forloop. по словам foreach, это почти в два раза быстрее. Потому что foreachработает с экземпляром перечислителя. это создать GetEnumarator() и вызвать часть кода для каждого элемента списка. Это приводит к снижению производительности.

Что касается метода ForEach, ниже я поделился содержимым метода List Object из исходного кода. Видно, что на его основе используется цикл for. Но он использует Action delegate. Кроме того, он выполняет множество проверок нулевых значений и версий. Поэтому производительность снижается.

Используйте, если можете, емкость в списках

Есть ли смысл ограничивать список емкостью? если вы находитесь в ожидании производительности, да, это имеет смысл.

В результатах тестов x почти на 63% быстрее, чем в обычном списке. Это число увеличивается до 73% в тесте емкости 1000. Также Распределите размеры слишком низко в соответствии с обычным списком. Причина этого в том, что списки с емкостью работают как массивы.

Используйте StringBuilder, насколько это возможно

Я использовал обычные операторы и строковые методы до того, как услышал StringBuilder. Я не думал, что между ними есть разница. Но есть существенная разница в производительности. Также я не делился кодом теста, чтобы избежать беспорядка. Если вы исследуете код, вы можете получить доступ здесь.

Я разделяю код теста на крошечные строковые процессы и тяжелые строковые процессы. Результаты получаются невероятно разными. Если мы изучим результаты, использование StringBuilderdefinitely приведет к увеличению производительности. Если мы рассмотрим крошечный строковый процесс, то потребуется время для создания StringBuilderintance. Поэтому может быть нелогично использовать его для вашего крошечного строкового процесса.

Не используйте параметр IEnumrable

Изменяет ли что-нибудь указание типа параметра как IEnumerableor List? Да, меняется. Когда параметр передается как IEnumerable, в списке выполняются операции упаковки и распаковки.

Вы заметили, что параметры в фрагменте кода, который я привел выше, отличаются. Когда вы передаете список как IEnumerable, он упаковывает как AsEnumerable()method. Из-за этого происходит потеря производительности. Вы можете наблюдать это в бенчмарк тесте.

Общие представления массивов и списков

Сравнение некоторых списков было сделано под этим заголовком. Конечно, вы должны определить, какой из них использовать по сценарию. Этот контрольный тест может изменить ваш выбор.

В этой статье я рассказал о множестве маленьких хитростей, которые повлияют на производительность. Моя цель здесь состояла в том, чтобы показать, что разработчики могут добиться значительного прироста производительности с небольшими изменениями. Я надеюсь, что я был успешным. Стоит помнить, что все коды вы можете найти здесь на github. Вам может понравиться репо и статья для поддержки.