Способы повысить эффективность [закрытого] кода C#

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

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

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

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

Примером отличного и бесплатного профилировщика для .NET является EQATEC Profiler.

«Я бы предпочел быстро исполняющийся грязный код чем-то более элегантным или чистым, но медленнее».

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

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

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

Хотя эти ссылки, которые вы предоставили, ценны, не делайте таких вещей заранее, сначала измерьте, а потом оптимизируйте.

edit:

http://www.codinghorror.com/blog/2009/01/the-sad-tragedy-of-micro-optimization-theater.html

Когда использовать StringBuilder?

В какой момент использование StringBuilder становится незначительным или накладным?

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

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

Я полагаюсь на чисто ручной метод составления профиля. Это пример нахождения серии точек для оптимизации, что привело к ускорению в 43 раза.

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

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

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

Микрооптимизируйте разумно - это как зеркало из Гарри Поттера: если вы не будете осторожны, то проведете там все свое время и ничего больше не сделаете, не получив многого взамен.

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

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

Самое важное в этом вопросе следующее: Не оптимизируйте преждевременно!

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

Думать об оптимизации во время написания первой версии - это в основном пустая трата времени и сил.