Under the Hood of .NET Memory Management / Под капотом у памяти в .Net: What`s Coming Next

В следующей части книги мы взглянем на .NET и CLR с точки зрения памяти. Мы рассмотрим несколько распространённых программных структур и идиом, а также то, какую роль играет память в некоторых распространённых проблемах с производительностью. Глава 4 будет посвящена особенностям .NET Framework в целом, а в главе 5 мы сосредоточим внимание на конкретных типах приложений или конкретных компонентах приложения.

_exp_ 03.01.20 в 06:41

Очевидно, что тема обширная, и, хотя в этих главах и упоминаются проблемы, с которыми вы можете столкнуться, всегда имейте в виду, что все приложения отличаются друг от друга. Несмотря на то, что мы описываем обобщённые примеры, конкретные решения могут быть уникальными для конкретных архитектур приложений. Разумеется, мы просто не можем описать все возможные решения, но разработчики и архитекторы смогут воспользоваться содержанием следующих нескольких глав, чтобы определить и исправить проблемы в своих собственных приложениях и инфраструктурах.

_exp_ 03.01.20 в 06:58

Язык.
Представленные примеры написаны на C# (если явно не сказано обратное), но информация, охватываемая главами, верна для многих языков, соответствующих общеязыковой спецификации (common language specification, CLS) – информация, данная здесь, будет точно так же верна для VB.NET. Другие языки на основе .NET Framework могут ставить свои уникальные задачи, но они не входят в сферу охвата этой книги. Такие языки как F# или Boo расширяют систему типов и поддерживают особенности языка, выходящие за рамки традиционных языков .NET. Эти особенности предоставляются компилятором, так как, в конечном итоге, весь код для .NET после компиляции можно свести к одному и тому же набору инструкций CIL.

_exp_ 03.01.20 в 07:17

Конечно, в некоторых языках некоторые проблемы, с которыми вы можете столкнуться, работая с C# или VB.NET, решаются более эффективно. Какой бы захватывающей эта тема не была, она тоже не входит в сферу охвата этой книги, и, кроме того, из-за растущего числа языков программирования, постоянно расширяется.

_exp_ 03.01.20 в 07:23

Наилучшие практики написания кода.
Вы можете до бесконечности оптимизировать ваш код, чтобы улучшить производительность или уменьшить потребление памяти, если вам больше нечем заняться. Но нужно думать и о других показателях – таких, как возможность поддержки, безопасность и продуктивность. Часто наилучшие для одной цели практики написания кода уже меньше подходят для другой. Вопрос, который вы должны себе задать: "Как мне наиболее эффективно оптимизировать свой код, учитывая все эти цели?". В списке ниже изложены некоторые разумные принципы, следование которым позволяет писать код, хорошо работающий в большинстве распространённых ситуаций с минимальными издержками по другим показателям. Возможно, вам не знакомы какие-то из терминов или концепций, упомянутые в списке, но к концу этой части они будут вам знакомы.
Используйте интерфейс IDisposable с паттерном Disposable, чтобы очищать неуправляемые ресурсы, и подавляйте финализацию в методе Dispose, если никакой другой финализации не требуется.

_exp_ 03.01.20 в 08:36

Используйте оператор using, чтобы определить область видимости disposable объекта, если это не вызовет исключение.

_exp_ 03.01.20 в 08:41

Используйте StringBuilder, когда количество конкатенаций строк неизвестно или содержится в цикле.

_exp_ 03.01.20 в 08:44

Инициализируйте capacity объекта StringBuilder разумным значением, если это возможно.

_exp_ 03.01.20 в 08:46

Используйте ленивую инициализацию, чтобы отложить стоимость членов класса, если в них нет необходимости при создании объекта.

_exp_ 03.01.20 в 08:51

Используйте структуры, чтобы хранить любые неизменяемые одиночные значения размером не больше 16 байтов, которые не будут часто упаковываться.

_exp_ 03.01.20 в 08:56

Переопределяйте методы GetHashCode и Equals у структур.

_exp_ 03.01.20 в 08:58

Помечайте все поля структуры как readonly.

_exp_ 03.01.20 в 09:01

Используйте ключевое слово readonly для тех полей классов, которые должны быть неизменяемыми.

_exp_ 03.01.20 в 09:04

Имплементируйте INotifyPropertyChanged на тех компонентных классах, которые могут использоваться в привязке клиентов.

_exp_ 03.01.20 в 09:08

Избегайте хранить в памяти большие графы объектов.

_exp_ 03.01.20 в 09:10

Избегайте использования беззнаковых численных типов (кроме байта).

_exp_ 03.01.20 в 09:12

Предпочитайте CLS-совместимые типы.

_exp_ 03.01.20 в 09:15

Помните про замыкание, когда используете анонимные функции.

_exp_ 03.01.20 в 09:19

Не передавайте делегатов методам расширения IQueryable.

_exp_ 03.01.20 в 09:22

Избегайте излишних агрегатных функций в запросах LINQ.

_exp_ 03.01.20 в 09:26

Используйте статические методы, когда нет необходимости получать доступ к состоянию или менять его.

_exp_ 03.01.20 в 09:29

Инициализируйте коллекции (например, List<T>) с заданным размером, если он известен.

_exp_ 03.01.20 в 09:32

Для больших элементов используйте контент, а не внедрённые ресурсы.

_exp_ 03.01.20 в 09:36

В приложениях, размещённых на IIS, установите значение атрибута //compilation/system.web/compilation/debug равным false, прежде чем выпускать в продакшен.

_exp_ 03.01.20 в 09:40

Удаляйте обработчики событий, прежде чем избавляться от объекта.

_exp_ 04.01.20 в 08:30

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

_exp_ 04.01.20 в 20:54