Последствия для производительности .net Events

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

Я понимаю проблемы, связанные с неправильным использованием, и я знаю, что они просто специальный делегат многоадресной рассылки, но с учетом сценария, в котором есть не более одного слушателя, почему использование события над вызовом метода считается "дорогим"?

Update:

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

Ответ 1

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

Быстрый и простой тест с выпуском не под отладчиком, скомпилированный под 4.0 как "любой процессор" и работающий на 64-битных Windows 7:

Другое Редактирование. Здесь лучший результат. См. код для его работы

10000000 direct reference calls     :   0.011 s
10000000 calls through an interface :   0.037 s
10000000 invocations of an event    :   0.067 s
10000000 calls through Action<int>  :   0.035 s

Итак, в прямом "ничего не тестируйте" с десятью миллионами звонков, событие добавляет 0,474 сек [ редактировать, только 0,26 сейчас на гораздо более качественной машине, все еще примерно вдвое больше]

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

Ответ 2

В .NET 2.0 вызов делегата так же быстро, как вызов метода интерфейса. Они даже кажутся немного быстрее.

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

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

Ответ 3

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

Я бы просто рассмотрел, что имеет больше смысла в вашем приложении, используя события или вызывая метод и выбирая лучший вариант. Основное различие заключается в том, что объект A генерации событий не должен знать своего слушателя (ов). Тот же объект A, вызывающий метод, должен знать экземпляр для его вызова. Где вы хотите установить зависимость?