Использование делегатов замедляет мои программы.NET?

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

(Аналогично исключения при надлежащем использовании редко на самом деле вызывают проблему производительности.)

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

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

Просто маленькое дополнение к сообщению Jon: при использовании нормальным способом C# (т.е. через лямбды / анонимные методы / обработчики событий / и т.д.), затем они определенно очень быстры - но отмечают, что другое важное использование делегатов может быть должно выполнить динамический код (или методы, созданные во времени выполнения или существующие методы через отражение и Делегата. CreateDelegate). При использовании этим вторым способом предложение делегатов очень значительное улучшение скорости (по сравнению с отражением Вызывают и т.д.).

Не стесняйтесь использования делегатов. И, в частности, если в сомнении - измеряют его для реалистического кода: это бессмысленно, требуются ли 1 или 100 микроласок*, если это все еще только составляет 0,01% Вашего полного времени выполнения.

* = просто некоторое произвольно небольшое количество времени...

Я работаю над Windows CE, таким образом, такого рода вещь является иногда немного более подходящей. Например, нахальное приложение отражения может действительно причинить боль так, мы склонны избегать отражения, где разумный (очевидно небольшие приложения отражения прекрасны). Очевидно, я не делаю такого безумия на рабочем столе.

Я услышал людей murmour о делегатах и производительности CE, но, что касается меня ее чрезвычайная пустая болтовня. Я слышал, что это "замедляет вызов метода на 30%", но если это составляет 30% дрянного алгоритма затем, отказ которого - это? Другой замедляется в CE, виртуальные методы, поскольку нет никакой справочной таблицы, он вручную работает их в первый раз и кэширует результат. Это означает, если Вы моча далеко вся Ваша память, те кэши будут очищены и она закончится в следующий раз хита перфекта вокруг. Но это рассмотрело, необходимо ли выбросить полезные навыки ООП ради производительности?

Я нахожу, что многие из них "OMG не используют это, это слишком медленно", просто оправдания. Главным образом оправдания, потому что люди не знают то, что является действительно неправильным с их приложением и его легким обвинить некоторую внутреннюю работу CLR вместо их собственного кода. Если бы Ваша производительность сосет затем, я счел бы, что 99,9% времени, можно изменить что-то в части приложения или дизайна, который не выбрасывает инструменты и результаты в намного лучших улучшениях.

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

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

Это обычно сводится к компромиссу между элегантностью кода и производительностью. Позволяет говорят, что Вы сделали наиболее замечательно изящную, удобную в сопровождении и понятную кодовую базу в мире. Как только мы добавляем некоторую оптимизацию производительности, мы начинаем объединяться в облако, код с некоторыми возможно противостоят интуитивному, очень специализированному материалу. Если бы мы перешли к городу при оптимизации его, то мы могли бы возможно сделать сохранение производительности, говорят 5, или 10 процентов, но в процессе полностью уничтожают элегантность кода.

Вопрос, "Действительно ли это стоит того?".

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