Contents
Типові причини низької працездатності в .Net Програмах
-
Причиною є збирання .Net програм на MSIL коді.
MSIL – це мова збірки (схожа на Assembler). Кожен .Net-програма складена з MSIL-команд. До запуску програми, CLR-платформа перекладає MSIL-коди на рідні CPU команди за допомогою JIT компілятора. З одного боку, цей процес забирає дещо часу. Наприклад, тому програма c++ запускається і працює швидше за с#-збірку. З другого боку, MSIL багатоплатформна мова, позаяк CLR є головним в побудові коректних CPU-команд. Тому ви можете запустити проєкт .Net на кожнім комп’ютері що підтримує CLR, на відміну від програми c++, який має бути перезібрана для різних CPU.
-
Вплив на роботу GC у неправильних руках.
GC – це збирач сміття, софт, що відповідальний за видалення невикористаних об’єктів для пам’яті. За замовченням він працює здебільшого добре: тре неприкріплену інфо у RAM коли програма потребує більше пам’яті. Можливо якось ви надумаєте, що маєте потребу використати деякі функції GC під часу запуску. Це цілком доречно, але хибне використання GC може зашкодити продуктивності.
-
Неоптимізовані пакування та розпакування об’єктів.
Наскільки відомо, види даних розділені на значені види та посилальні. Але також можна робити посилальні види значених видів (пакування) і значені види посилальних видів (розпакування). Ці дії споживають пам’ять і ресурси CPU, і їх слід уникати за можливости.
-
Неоптимізоване використання потоків.
Маючи справу з довгими завданнями в одному потоці, програма блокує UI інтерфейс (якщо його використано). Крім того це точно довше, ніж у багато-потоковій програмі, коли є можливим розділити завдання на різні робочі процеси.
-
Дії із крупними Масивами у с#
Загалом, Масив використовують щоб зберігати збірку елементів. Але якщо доводиться складати елементи у велику збірку, Масив споживає багато ресурсів. Масив це визначена послідовність «місць» у пам’яті, тому його розмір не міняють просто так: спочатку створюють новий Масив з потрібною довжиною, затим попередній Масив копіюють до нового; відтак він може приймати нові елементи.
-
Дебаг мод.
Полагодження (дебагінг) .Net-збірки виконується за допомогою екстра-команд, що їх вставляють у MSIL код після компіляції. Так є можливим встановити точки-зупину, додати умови зупину тощо. Всі дії з полагодженням споживають додаткові ресурси.
-
х86 конфігурація додатку.
Коротко, відмінність між системами х86 та х64 в обсязі пам’яті, до якої CPU може одержати доступ і обробити. Архітектурні системи х86 можуть оперувати з меншим обсягом пам’яті протягом внутрішніх арифметичних дій, та можуть отримати доступ до меншого обсягу даних з RAM, ніж системи х64.
Як порихтувати типові причини нестачі продуктивности
-
.Net native збергіє UMP-збірку прямо до рідного коду CPU.
.Net Native – це технологія, яку використовують для збирання проєктів UWP для Віндовс 10 прямо до машинного коду. Це забезпечує такі переваги:
- Збільшення швидкості виконання
- Швидкий запуск додатку
- Поліпшене використання пам’яті
Аби застосувати .Net Native вам треба:
- Створити UMP проєкт
- Увімкнути .Net Native в налаштуваннях
- Побудувати проєкт
-
Не викликайте GC коли на те нема потреби. Робіть нотатки для GC використовуючи деструктори. Подбайте про некеровані ресурси за допомогою IDisposable інтерфейсу.
Засади керування пам’яттю.
- GC вирішує самостійно, за своїми правилами, коли і котрий об’єкт слід видалити з купи.
- Деконструктор об’єкту (деякий екземпляр класу) – це метод, що його викликає GC перед видаленням об’єкту.
- IDisposable – це інтерфейс котрий використовують для шаблону disposing. IDisposable об’єкти мають метод Dispose (Вивільнення) який слід застосовувати для чистки некерованих ресурсів після завершення роботи об’єкту. Метод Dispose не викликається GC.
- Ви можете контролювати поведінку збирача сміття за допомогою класу GC.
-
Для виконання кількох задач водночас програмі треба створити кілька потоків. Асинкронічни завдання можуть збільшити продуктивність і розв’язати проблему блокування UI.
Зазвичай програма працює у однопоточному режимі. Також якщо асинхронні інструменти не використовують, робота відбувається синхронно. Засади керування потоками:
- «Threading» простір імен
- клас Thread – дозволяє створювати і контролювати потоки. Створення потоку є процесом що забирає ресурси, тому надто багато початих потоків можуть знизити продуктивність. Якщо ваш комп’ютер багатоядерний, ви можете виконувати инші команди в инших потоках паралельно.
- Оскільки починання нових потоків ресурс-затратне, можете позичити деякі потоки з ThreadPool
- Якщо ваш комп’ютер не багатоядерний або паралельна робота не в потребі, нема надібності користати потоки взагалі. Натомість, кращою опцією є застосувати клас Task. По-суті, Таск це надбудова Потоку. На додаток, вона помагає дуже простому контролю над «асинхронною роботою». Асинхронні задачі можна виконати паралельно, але в цілому CPU розділяє їх на кілька частин і запускає одну за одною як вважає. Це розв’язує проблему з блокованим UI і пришвидшує продуктивність.
-
Великі масиви беруть забагато ресурсів на переформування.
Краща альтернатива – List
. List Легко виконує додання, прибрання та переформування.
-
Релізна версія програми достеменно більш перспективна ніж DEBUG.
To build a project in release mode, turn it on in visual studio. Аби побудувати проєкт в реліз-режимі, увімкніть його у visual-studio.
-
64-розрядні системи більш працездатні ніж 84-і
Щоб зробить збірку у 64-й конфігурації, увімкніть її у visual studio.
Инші нюанси щоби збільшити працездатність у .Net
- Явний розбір Steams, HttpWebRequests, Interop services. Підсумовуючи, кожна річ що наслідує IDisposable має бути зрештою розібрана. (або із “using”-виразом)
- Ліниве завантаження екземплярів
- Паралельні цикли.
Awesome!!!