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

Question

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

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

Обновление:

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

Answer 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

Таким образом, в обычном тесте «ничего не делать» с десятью миллионами вызовов событие добавляет .474 сек. [ редактировать , только .026 теперь на намного лучшей машине, все еще примерно вдвое больше]

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

Answer 2

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

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

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

Answer 3

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

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