Ускорение C #

Question

Это на самом деле два вопроса, но они очень похожи, и для простоты я решил, что я просто свожу их вместе:

• Во-первых : Принимая во внимание устоявшийся проект на C #, какие есть приличные способы ускорить его помимо простой оптимизации в коде?

• Во-вторых : Каковы хорошие способы значительно повысить производительность при написании программы на C #?

Пожалуйста, держитесь подальше от общих методов оптимизации, если они не C # специфичны .

Ранее запрашивались Python , Perl и Java .

Answer 1

с макушки головы:

• Заменить неуниверсальные варианты классов контейнеров их родовыми аналогами
• Сократить бокс / распаковку. В частности, используйте дженерики, где это возможно, и обычно избегайте передачи типов значений как object.
• Для диалогов, использующих много динамических элементов управления: приостановите рисование до тех пор, пока не вставите все элементы управления, используя SuspendLayout / ResumeLayout. Это особенно помогает при использовании контейнеров макетов.

Answer 2

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

• Измерение производительности при реалистичных нагрузках
• Иметь четко определенные цели, которые вам помогут
• Используйте хороший профилировщик
• Оптимизация архитектуры / дизайна относительно рано
• Микрооптимизация только тогда, когда у вас есть проверенная проблема

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

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

РЕДАКТИРОВАТЬ: Другие ответы, предлагающие использование дженериков, StringBuilder и т. Д., Конечно, правильно. Я (вероятно, ошибочно) предположил, что эти оптимизации были слишком "очевидными";)

Answer 3

Одна простая вещь - убедиться, что для вашей конфигурации сборки установлено значение «Release». Это позволит оптимизировать и исключить отладочную информацию, уменьшая размер вашего исполняемого файла.

Дополнительная информация на MSDN , если необходимо.

Answer 4

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

Тогда начинайте спрашивать, как улучшить производительность.

Любой, кто делает какие-либо общие заявления, такие как «избегать размышлений», не понимая ни вашего профиля производительности, ни вашей проблемной области, должен быть застрелен (или, по крайней мере, переучен). И учитывая размер .Net ландшафта, говорить об оптимизации C # практически бессмысленно: мы говорим о WinForms, ASP.Net, BizTalk, Workflow, SQL-CLR? Без контекста даже общие рекомендации могут быть в лучшем случае пустой тратой времени.

Подумайте также, что вы подразумеваете под «ускорением» и «повышением производительности». Вы имеете в виду более высокую эффективность использования ресурсов или меньшее предполагаемое время ожидания для конечного пользователя (при условии, что оно есть)? Это очень разные проблемы для решения.

Учитывая форум, я чувствую себя обязанным отметить, что в Code Complete есть достаточно хорошее освещение этих тем. Не C # конкретный ум. Но это хорошо. Имейте в виду, что микрооптимизации для конкретного языка вполне могут быть включены в следующую версию того компилятора, который вы используете, и если разница между for и foreach имеет для вас большое значение, вы все равно, вероятно, пишете на C ++, верно?

[Мне понравился ANTS Profiler от RedGate, но я думаю, что его можно улучшить]

С этим по пути, некоторые мысли:

• Используйте тип (SomeType) в предпочтении instance.GetType (), когда это возможно
• Использование foreach в предпочтении для
• Избегайте бокс
• До (я думаю) 3 строки это нормально делать StringA + StringB + StringC. После этого вы должны использовать StringBuilder

Answer 5

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

Answer 6

Используйте композицию вместо наследования, ограничьте упаковку / распаковку, используйте общие коллекции, используйте циклы foreach вместо for {} со счетчиком и освободите ресурсы со стандартным шаблоном Dispose.

Они подробно описаны в превосходной книге Effective C #.

Answer 7

• Используйте StringBuilder вместо множества конкатенации строк. Строковые объекты являются атомарными, и любая модификация (добавление, наверх, заполнение и т. Д.) Фактически генерирует совершенно новый строковый объект, а не модифицирует оригинал. Каждая новая строка должна быть выделена и, в конце концов, собрана сборщиком мусора.

• Обобщение предыдущего утверждения: попробуйте повторно использовать объекты, а не создавать их много и много. Выделение и сборка мусора могут быть простыми, но они снижают вашу производительность.

• Обязательно используйте предоставленные библиотеки Microsoft для большинства вещей. Классы, предоставляемые платформой, часто используют функции, которые недоступны или труднодоступны из вашего собственного кода C # (т.е. обращаются к собственному Windows API). Встроенные библиотеки не всегда являются наиболее эффективными, но чаще всего.

• Написание асинхронных приложений никогда не было проще. Посмотрите на такие вещи, как класс BackgroundWorker.

• Старайтесь не определять структуры, если они действительно не нужны. Каждая переменная экземпляра класса содержит ссылку на фактический экземпляр, а каждая переменная экземпляра структуры содержит отдельную копию.

Answer 8

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

Answer 9

Для Windows Forms в XP и Vista: включите двойную буферизацию по всей плате. Это вызывает проблемы с прозрачностью, так что вы определенно захотите протестировать интерфейс:

protected override System.Windows.Forms.CreateParams CreateParams { 
    get { 
        CreateParams cp = base.CreateParams; 
        cp.ExStyle = cp.ExStyle | 0x2000000; 
        return cp; 
    } 
} 

Answer 10

Это верно для любого языка, а не только для C #

1. Для существующего приложения не делайте ничего , пока не узнаете, что делает его медленным. ИМХО, это лучший способ.

2. Для новых приложений проблема в том, как учат программистов. Их учат делать из мухи слона. После того, как вы оптимизировали несколько приложений, используя этот , вы будете знакомы с проблемой того, что я называю «скачущей общностью» - слой за слоем «абстракции», а не просто спрашиваете, для чего нужна проблема. Лучшее, на что вы можете надеяться, - это бегать за ними, рассказывая им о проблемах с производительностью, которые они только что добавили, чтобы они могли убирать их с ходу.