Let us have a party :)

HI FOLKS !!!! Ho-ho-ho, it is time to have a party, my dear friends !!! 23 JULY 2014, somewhere in Lviv :)

Scalability in .Net

Що ж таке Scalability? Scalability на нашу мову перекладається як «маштабовність» і є здатністю\властивістю системи, мережі, процесу обробити більший обсяг роботи або бути легко розширеною без значної втрати  продуктивності(Performance). Але визначити scalability системи як правило дуже тяжко, оскільки потрібно визначати специфічні вимоги для масштабованості(Scalability) системи. Існує 2 вида Scalability – вертикальна і горизонтальна. Вертикальна – то покращення однієї машини(збільшення памяті, швидший процессор). Горизонтальна – це розподіл нагрузки\процесів на декілька машин.

Scalability і Performance пов’язані між собою. Якщо система погано розширюється то питання строїть в продуктивності. Отже на сам перед потрібно чітко визначити вимоги до системи, яку ми плануємо проектувати. Не забувати, що продукт можемо писати для 10 юзерів, які часто переростають в десятки тисяч, і з неправильно продуманою системою з’являється багато роботи для програмістів переробляти і переробляти код і систему для досягнення нових цілей. Як писати код для оптимальної продуктивності я описувати не буду, оскільки недавно гарно про це було написано в нашому блозі(http://dotnetbanda.blogspot.com/2014/07/c.html).

Якщо притримуватися гарного коду і принципів правильного написання – то вже наша система бути мати хороший показник масштабованості. Але існують ще техніки для покращення її.

Від Майкрософта поради:

-           Не чекайте – процес не повинен чекати довше чим потрібно

-           Не боріться за ресурси – Займайте ресурси якомога пізніше, але звільняйте їх якомога швидше

-           Дизайн для замінності – дві або більше операції називаються замінними якщо вони можуть бути застосовані в будь-якому порядку і отримати той самий результат

-           Дизайн для взаємозамінності – управління ресурсами, так, щоб вони могли бути взаємозамінними

-           Розподіл ресурсів і активностей – мінімізуйте відносини між ресурсами і активностями

Цікаві ссилки:

http://msdn.microsoft.com/en-us/library/aa292172(v=vs.71).aspx

http://msdn.microsoft.com/en-us/library/ff649152.aspx

Singleton vs static class

Singleton чи static class

Дуже часто на співбесідах запитують яка різниця між статичним класом та сінглтоном. Як правило таке питання не завдає труднощів, адже на просторах інтернету дуже багато відповідей. Зазвичай ми чуємо щось на кшталт: сінглтон це класс який існує лише в одному екземплярі, і далі розповідь про обмеження статичного класу…

Спробую описати дещо з іншого боку. Статичний клас мені нагадує структурне програмування. А сінглтон це об’єкт, значить це вже ООП. А раз ООП, то ми можемо наслідувати сінглтон від інших класів, інтерфейсів, можемо використовувати об’єкт в Dependency Injection, та навіть з деякими «костилями» унаслідуватись від сінглтона.

Как писать код на C # для достижения оптимальной производительности.

Заметки о том, как писать код на C # для достижения оптимальной производительности.

Термин производительность в целом относится к скорости выполнения программы. Иногда вы можете увеличить скорость выполнения, следуя определенным правилам написания исходного кода. В некоторых случаях, следует использовать профайлеры и метрики, чтобы убедиться в том, что приложение работает так быстро, как это возможно. В других, вам не придется выполнять такую ​​оптимизацию, так как приложение и так работает приемлемо быстро.
При измерении и оптимизации производительности, желательно следовать таким общим принципам:
- Начните с определения целей по производительности и измерения эффективности программы, чтобы в последующем иметь возможность определить, когда и где ваш код или его часть не удовлетворяет поставленным целям.
- Пишите свой ​​код изначально правильно, следуя общепринятым принципам проектирования, используя coding стандарты принятые на вашем проекте или организации.
- Оптимизируйте код позже, но только если вы определили, что он не способствует достижению поставленных целей по производительности. Код, который оптимизирован для выполнения часто более трудно читать и поддерживать. Как правило, лучше написать код, который читается, надежной и обслуживании, даже если это немного медленнее, чем самый оптимизированный код, что вы могли бы написать.
- Если вы должны оптимизировать, начните с самых медленных частей программы. Если выяснится, что программа не отвечает требованиям производительности, определите конкретные места, где производительность может быть улучшена, и какие вопросы производительности являются основными причинами этой проблемы. Как правило, не имеет смысла оптимизировать метод, который вызывается редко (лучше потратить время на более весомые задачи).

Рекомендации Microsoft

Рекомендации Microsoft, о том, как построить .NET приложения, которые отвечают требованиям производительности. Руководящие принципы относится к различным ролям, участвующих в SDLC, в том числе архитекторов, дизайнеров, разработчиков, тестировщиков и администраторов. Ниже приведена диаграмма.

Несколько основных советов/рекомендаций специфических для С#

Есть много различных «особенностей» которым те или иные источники советуют следовать. Я приведу несколько самых простых и базовых примеров (их в общем то действительно не много).

Boxing и Unboxing

Данные операции являются вычислительно дорогими процессами. Применительно к value типам, данные операции предусматривают перемещение значения из стека (stack) в управляемую кучу (managed heap) и обратно. Это может дать замедление до 20 раз.

Подробнее можно почитать тут.

Strings – работа с большими строками

При необходимости работы с большими строками следует предпочитать StringBuilder Class использованию оператора «+». Подробнее можно почитать тут.

Destructors

Следует избегать объявления пустых destructor-ов. Это приводит к неоправданному использования ресурсов и понижению производительности.

Design with ValueTypes

По возможности используйте простые типы и структуры (struct) где это возможно. Операции со стеком (stack) быстрее чем операции с кучей (managed heap). Сравнение.

Цикл for быстрее чем foreach

Если это возможно предпочитайте использование цикла for вместо foreach.

Генерация исключений

Генерируйте как можно меньше исключений (throw new Exception(); или throw;). Операция весьма дорогостоящая и если это возможно, то не стоит часто ее использовать.

«Спасибо Кеп»

Несколько очевидных вещей:
- будьте внимательны с рекурсивными вызовами методов
- сериализация иерархического объекта элементы которого имеют ссылки друг на друга
- reflection вещь хорошая, но злоупотреблять не стоит

Заключение

На производительность в целом больше влияют архитектурные моменты чем особенности языка программирования J

Полезные ссылки

http://msdn.microsoft.com/en-us/library/ms973839.aspx

http://en.wikipedia.org/wiki/Gang_of_Four_(band)

http://msdn.microsoft.com/en-us/library/ff649152.aspx

Як перевизначати ? overloading і overriding в .NET

label start:

Все що в світі виникло як правило виникало в наслідок лінтяйства вирішення якихось проблем, на мою думку для розуміння будьчого треба завжди починати з розуміння того які проблеми воно вирішує. Якшо мислити таким шляхом то з часом розумієш шо проблеми приблизно у всіх однакові але вирішення їх бувають різними і цікавими. Які проблеми вирішує те про що я зараз буду писати ? та стопудово зручність і читабельність коду. Чи можна жити без цього ? можна але не варто, ці реці не є якомось віддальонним ізвратом дотнета про який ніхто ніде не чув і не використовує.