Подсказки для оптимизации [закрытых] программ C#/.NET

Получите хороший профайлер.

Даже не пытайтесь оптимизировать C# (да и вообще любой код) без хорошего профилировщика. На самом деле, очень полезно иметь под рукой как выборочный, так и трассирующий профилировщик.

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

Первые три шага профилирования всегда должны быть следующими: 1) измерьте, 2) измерьте, а затем 3) измерьте....

Я не особо стараюсь оптимизировать свой код, но иногда я просматриваю и использую что-то вроде reflector, чтобы вернуть свои программы в исходники. Интересно потом сравнить то, что я сделал неправильно, с тем, что выдаст reflector. Иногда я обнаруживаю, что то, что я сделал в более сложной форме, было упрощено. Возможно, это не оптимизирует ситуацию, но помогает мне увидеть более простые решения проблем.

Рекомендации по оптимизации:

1. Не делайте этого, если в этом нет необходимости
2. Не делайте этого, если дешевле бросить на решение проблемы новое оборудование вместо разработчика
3. Не делайте этого, если не можете измерить изменения в производственной среде. эквивалентной среде
4. Не делайте этого, если вы не знаете, как использовать CPU и профилировщик памяти
5. Не делайте этого, если это сделает ваш код нечитаемым или не поддерживаемым

Поскольку процессоры продолжают становиться быстрее, основным узким местом в большинстве приложений становится не CPU, а пропускная способность: пропускная способность внечиповой памяти, пропускная способность диска и пропускная способность сети.

Начните с дальнего конца: используйте YSlow, чтобы понять, почему ваш веб-сайт работает медленно для конечных пользователей, затем вернитесь назад и исправьте обращения к базе данных, чтобы они были не слишком широкими (столбцы) и не слишком глубокими (строки).

В очень редких случаях, когда стоит сделать что-то для оптимизации использования процессора, будьте осторожны, чтобы не повлиять на использование памяти: Я видел "оптимизации", в которых разработчики пытались использовать память для кэширования результатов, чтобы сэкономить циклы процессора. Чистый эффект заключался в уменьшении доступной памяти для кэширования страниц и результатов базы данных, что делало работу приложения намного медленнее! (См. правило об измерении.)

Я также видел случаи, когда "тупой" неоптимизированный алгоритм побеждал "умный" оптимизированный алгоритм. Никогда не стоит недооценивать, насколько хорошо авторы компиляторов и разработчики микросхем научились превращать "неэффективный" циклический код в суперэффективный код, который может работать полностью в памяти кристалла с конвейеризацией. Ваш "умный" древовидный алгоритм с развёрнутым внутренним циклом, считающим в обратном направлении, который вы считали "эффективным", может быть побеждён просто потому, что он не смог остаться в памяти кристалла во время выполнения. (См. правило об измерении.)

У людей есть забавные представления о том, что на самом деле имеет значение. Stack Overflow полон вопросов, например, о том, является ли ++ i более «производительным», чем i ++ . Вот пример реальной настройки производительности , и это в основном та же процедура для любого языка. Если код просто написан определенным образом «потому что он быстрее», то это предположение.

Конечно, вы специально не пишете глупый код, но если бы угадывание работало, не было бы необходимости в профилировщиках и методах профилирования.

Похоже, что оптимизация в наши дни - потерянное искусство.

Был день, когда изготовление, скажем, микроскопов практиковалось как искусство. Оптические принципы были плохо изучены. Стандартизации деталей не было. Трубки, шестерни и линзы должны были изготавливаться вручную высококвалифицированными рабочими.

В наши дни микроскопы производятся как инженерная дисциплина. Основные принципы физики чрезвычайно хорошо изучены, стандартные детали широко доступны, и инженеры-конструкторы микроскопов могут сделать осознанный выбор, как наилучшим образом оптимизировать свой прибор для задач, для которых он предназначен.

То, что анализ производительности - это «потерянное искусство», это очень и очень хорошая вещь. Это искусство практиковалось как искусство . К оптимизации следует подходить так, какова она есть: инженерная проблема , которую можно решить путем тщательного применения твердых инженерных принципов.

За эти годы меня десятки раз спрашивали о моем списке «советов и приемов», которые люди могут использовать для оптимизации своего vbscript / jscript / активных страниц сервера / VB / кода C #. Я всегда этому сопротивляюсь. Упор на «советы и рекомендации» - это совершенно неправильный подход к производительности. Таким образом, получается код, который трудно понять, сложно рассуждать, трудно поддерживать, который обычно не намного быстрее, чем соответствующий простой код.

Правильный подход к производительности - подходить к ней как к инженерной проблеме, как и к любой другой проблеме:

• Ставить значимые, измеримые, ориентированные на клиента цели.
• Создавайте наборы тестов, чтобы проверить свою производительность в соответствии с этими целями в реалистичных, но контролируемых и повторяемых условиях.
• Если эти комплекты показывают, что вы не достигаете своих целей, воспользуйтесь такими инструментами, как профилировщики, чтобы выяснить, почему.
• Оптимизируйте то, что профилировщик определяет как наихудшую подсистему. Продолжайте профилировать каждое изменение, чтобы четко понимать влияние каждого изменения на производительность.
• Повторяйте до тех пор, пока не произойдет одно из трех: (1) вы достигнете своих целей и отправите программное обеспечение, (2) вы пересмотрите свои цели в сторону уменьшения до того, что вы можете достичь, или (3) ваш проект будет отменен, потому что вы не смогли выполнить свои цели.

Это то же самое, что и любая другая инженерная проблема, например, добавление функции - установка ориентированных на клиента целей для функции, отслеживание прогресса в создании надежной реализации, устранение проблем по мере их обнаружения путем тщательного анализа отладки, продолжайте повторять, пока вы не отправите или не потерпите неудачу. Производительность - это особенность.

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

При работе с ORMs помните о N+1 Selects.

List<Order> _orders = _repository.GetOrders(DateTime.Now);
foreach(var order in _orders)
{
    Print(order.Customer.Name);
}

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