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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание! Этот перевод, возможно, ещё не готов.
Его статус: идёт перевод

Переведено на Нотабеноиде
http://notabenoid.org/book/78130/456344

Переводчики: _exp_