C# 6 Трикове за ефективност

Тази статия ще ви разкаже за подобряване на производителността на вашия код с няколко мини трика за .NET. На пръв поглед може да се предположи, че тези трикове са ненужни, но те ще доведат до абсолютни увеличения на производителността. Всички кодове за сравнение могат да бъдат намерени в репото на github тук. Готови ли сте да преминете границите?

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

Да предположим, че имаме 1000x1000 двуизмерен масив. И трябва да проверите един по един целия масив. Използвате ли array[i][j]или array[j][i] при извикване на елемент? Или казвате „какво значение има?“ Нека обясним.

Има две части от кода за сравнение на C# по-горе. На пръв поглед няма нищо лошо. Но резултатите от бенчмарка не го показват. Има увеличение на производителността от почти 60%. Освен това има различен разпределен размер. Причината е, че .NET се разхожда в паметта при извикване на елемент от вътрешността на масива. Така че повече пропуски между две повиквания, толкова по-голямо е влошаването на производителността. .NET наистина се грижи за местоположението на паметта.

Кой е по-добър? for срещу foreach срещу `List ForEach` цикли

Ние често използваме тези циклични структури. Но ние не изследваме от гледна точка на ефективността. Под това заглавие няма да разказвам от какво са те. Просто искам да видите разликите в производителността.

Има две части от кода за сравнение на C# по-горе. Това е просто извикващ елемент от списъка. В резултат от бенчмарк forloop работи най-добре досега. това е почти два пъти по-бързо според foreach. Тъй като foreachработи с екземпляр на изброител. създава GetEnumarator()и извиква кодовата част за всеки елемент от списъка. Това води до влошаване на производителността.

Що се отнася до ForEachmethod, споделих по-долу съдържанието на метода List Object от изходния код. Вижда се, че на базата на него се използва цикълът for. Но използва Action delegate. Също така прави толкова много нулеви проверки и проверки на версиите. Поради това производителността намалява.

Използвайте, ако можете капацитет в Списъци

Има ли смисъл списъкът да се ограничава до капацитет? ако очаквате производителност, да, има смисъл.

В резултатите от бенчмарка, x почти %63 по-бърз от нормалния списък. Този брой нараства до %73 при 1000 теста за капацитет. Също така Разпределете твърде ниски размери според нормалния списък. Причината за това са списъци с капацитет, които работят като масиви.

Използвайте StringBuilder, доколкото е възможно

Използвах нормални оператори и низови методи, преди да чуя StringBuilder. Не мислех, че има разлика между тях. Но има съществена разлика в производителността. Също така не споделих кода за сравнение, за да избегна бъркотията. Ако разглеждате кода, можете да получите достъп тук.

Разделям кода за бенчмарк на малки низови процеси и тежки низови процеси. Резултатите излизат невероятно различни. Ако разгледаме резултатите, използването на StringBuilder определено води до повишаване на производителността. Ако разгледаме процеса на малък низ, отнема време за създаване на StringBuilderintance. Следователно може да е нелогично да го използвате за вашия малък процес на низ.

Не използвайте параметър IEnumrable

Указването на типа параметър като IEnumerableили List променя ли нещо? Да, променя се. Когато параметърът е предаден като IEnumerable, в списъка се извършват операции за поставяне в кутия и разопаковане.

Забелязахте, че параметрите са различни в кодовия фрагмент, който дадох по-горе. Когато подадете списък като IEnumerable, той прави бокс като AsEnumerable()method. Поради това се получава загуба на производителност. Можете да наблюдавате това в бенчмарк теста.

Общи изпълнения на масиви и списъци

Под това заглавие е направено сравнение на някои списъци. Разбира се, вие трябва да определите кой да използвате според сценария. Този сравнителен тест може да промени избора ви.

В тази статия говорих за много малки трикове, които ще повлияят на производителността. Целта ми тук беше да покажа, че разработчиците могат да постигнат големи печалби в производителността с малки промени. Надявам се да имам успех. Струва си да запомните, че можете да намерите всички кодове тук в github. Можете да харесате репото и статията за поддръжка.