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

Question

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

Я избегаю их, потому что действительно не понимаю, делают ли они мои программы медленнее. Я знаю, вызывает ли я (перехват) исключение, которое потребляет немного ресурсов процессора, но я не знаю ни о делегатах и ​​событиях, ни о том, что с ними делает .NET

Answer 1

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

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

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

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

Answer 2

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

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

* = просто какое-то сколь угодно малое количество времени ...

Answer 3

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

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

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

Answer 4

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

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

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

Вопрос: «Стоит ли это того?».

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