Reading mode

PERFORMANCE

Типові причини низької працездатності в .Net Програмах

  1. Причиною є збирання .Net програм на MSIL коді.

    MSIL – це мова збірки (схожа на Assembler). Кожен .Net-програма складена з MSIL-команд. До запуску програми, CLR-платформа перекладає MSIL-коди на рідні CPU команди за допомогою JIT компілятора. З одного боку, цей процес забирає дещо часу. Наприклад, тому програма c++ запускається і працює швидше за с#-збірку. З другого боку, MSIL багатоплатформна мова, позаяк CLR є головним в побудові коректних CPU-команд. Тому ви можете запустити проєкт .Net на кожнім комп’ютері що підтримує CLR, на відміну від програми c++, який має бути перезібрана для різних CPU.

  2. Вплив на роботу GC у неправильних руках.

    GC – це збирач сміття, софт, що відповідальний за видалення невикористаних об’єктів для пам’яті. За замовченням він працює здебільшого добре: тре неприкріплену інфо у RAM коли програма потребує більше пам’яті. Можливо якось ви надумаєте, що маєте потребу використати деякі функції GC під часу запуску. Це цілком доречно, але хибне використання GC може зашкодити продуктивності.

  3. Неоптимізовані пакування та розпакування об’єктів.

    Наскільки відомо, види даних розділені на значені види та посилальні. Але також можна робити посилальні види значених видів (пакування) і значені види посилальних видів (розпакування). Ці дії споживають пам’ять і ресурси CPU, і їх слід уникати за можливости.

  4. Неоптимізоване використання потоків.

    Маючи справу з довгими завданнями в одному потоці, програма блокує UI інтерфейс (якщо його використано). Крім того це точно довше, ніж у багато-потоковій програмі, коли є можливим розділити завдання на різні робочі процеси.

  5. Дії із крупними Масивами у с#

    Загалом, Масив використовують щоб зберігати збірку елементів. Але якщо доводиться складати елементи у велику збірку, Масив споживає багато ресурсів. Масив це визначена послідовність «місць» у пам’яті, тому його розмір не міняють просто так: спочатку створюють новий Масив з потрібною довжиною, затим попередній Масив копіюють до нового; відтак він може приймати нові елементи.

  6. Дебаг мод.

    Полагодження (дебагінг) .Net-збірки виконується за допомогою екстра-команд, що їх вставляють у MSIL код після компіляції. Так є можливим встановити точки-зупину, додати умови зупину тощо. Всі дії з полагодженням споживають додаткові ресурси.

  7. х86 конфігурація додатку.

    Коротко, відмінність між системами х86 та х64 в обсязі пам’яті, до якої CPU може одержати доступ і обробити. Архітектурні системи х86 можуть оперувати з меншим обсягом пам’яті протягом внутрішніх арифметичних дій, та можуть отримати доступ до меншого обсягу даних з RAM, ніж системи х64.

Як порихтувати типові причини нестачі продуктивности

  • .Net native збергіє UMP-збірку прямо до рідного коду CPU.

    .Net Native – це технологія, яку використовують для збирання проєктів UWP для Віндовс 10 прямо до машинного коду. Це забезпечує такі переваги:

    • Збільшення швидкості виконання
    • Швидкий запуск додатку
    • Поліпшене використання пам’яті

    Аби застосувати .Net Native вам треба:

    1. Створити UMP проєкт
    2. Увімкнути .Net Native в налаштуваннях
      dot-net-native-set-up
    3. Побудувати проєкт

  • Не викликайте 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.
    release mode

  • 64-розрядні системи більш працездатні ніж 84-і

    Щоб зробить збірку у 64-й конфігурації, увімкніть її у visual studio.
    conf
    conf-manager

    conf-manager-64

Инші нюанси щоби збільшити працездатність у .Net

Share this Post