Сравнение скорости вызова делегата без проверки на null и с проверкой

@titan4ik · 07.07.2020, 12:08. **Показов** 2344. **Ответов** 28

Студворк — интернет-сервис помощи студентам

Рекомендуется всегда использовать вызов делегата с проверкой на null
del?.Invoke(); (del - экземпляр делегата)
Допустим, нужно сделать миллион итераций в цикле с вызовом делегата в теле цикла.
Не внесет ли проверка на null существенной задержки по времени исполнения?
Я сейчас проверил (в режиме отладки с пом точек остановки) - практически никакой разницы не заметил.
Это нормально? То есть, всегда использовать вызов с проверкой?

@КОП · 07.07.2020, 23:26

Сообщение от Enifan

что быстрее / лучше - проверка на null или с пустым методом ?

Code
1
2
3
4
|    Method |       Mean |    Error |    StdDev | Rank |
|---------- |-----------:|---------:|----------:|-----:|
|  NullCall |   921.5 us | 2.581 us | 2.4141 us |    1 |
| EmptyCall | 1,803.9 us | 1.139 us | 0.9508 us |    2 |

@Fulcrum_013 · 08.07.2020, 00:59

Сообщение от Enifan

Что в вашем понимании здесь некорректно, за исключением invocationList, который был указан выше ?

Некорректно - это просто убрать проверку. А это ее полный алгоритмический аналог. indirect call/jump аккурат как замену ветвлению изобретали. Но быстрее он будет только при множестве вариантов за счет того что у ветвления выбор варианта будет O( log n) , у indirect call/jump O(1).

Сообщение от Enifan

Смысл не в том, чтобы избежать, а чтобы знать разницу

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

Добавлено через 45 минут

Сообщение от titan4ik

Это нормально? То есть, всегда использовать вызов с проверкой?

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

@escoult · 08.07.2020, 01:34

Сообщение от Enifan

Вопрос в том, почему эта альтернатива даже не рассматривается

Рассматривается. На StackOverflow этим темам по многу лет. Кто-то считает пустой делегат находкой, а потери в производительности незначительными. Кто то наоборот.

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

Проверка состояния объекта действие обычное, не выходящее за рамки программной логики. А создание объектов, которые ничего не делают - не совсем (хотя есть примеры, можно вспомнить Кнута с фиктивной ячейкой в массиве...). Из этих соображений, фиктивный делегат это и не альтернатива, а что то вроде трюка. Ну это мое личное мнение. Я думаю, что если объект ничего не делает, то он не должен создаваться. Не потому что ресурсы дороги или дешевы, а потому, что это нарушает логику.

@Usaga · 08.07.2020, 06:37

Сообщение от escoult

Кто-то считает пустой делегат находкой, а потери в производительности незначительными.

На самом деле это Null Object чистой воды. Со всеми вытекающими плюсами и минусами. Вы не забудете выполнить проверку на null, если она тупо не нужна. Я сторонник такого подхода, где это возможно и оправданно.

Хотя я не оспариваю, что это дороже (по скорости выполнения) простой проверки. Тут, как бы, два стула: на одном упрощение кода и увеличение его надёжности, на другом - вопрос производительности. Где-то удобнее первый стул, где-то - второй. Даже среди моих коллег нет однозначного мнения.

@Fulcrum_013 · 08.07.2020, 14:38

Сообщение от escoult

Не потому что ресурсы дороги или дешевы, а потому, что это нарушает логику.

Сообщение от Usaga

Даже среди моих коллег нет однозначного мнения.

А однозначного не будет в принципе. С точки зрения той парадигмы, в рамках которой родился каждый из способов, каждый из них абсолютно логичен, а второй нелогичен.
Если смотреть с точки зрения ООП то как бы логично что абстракция "выполнить действие" конкретизируется объектом выполняющим конкретное действие "не выполнять никаких действий". А вот проверка состояний извне абсолютно нелогична - состояние это внутреннее дело объекта, и никто извне о них знать ничего не должен.
Другое дело что манипуляция с заглушкой извне тоже не логична. Но тут оставаясь в рамках шарпа ничего не поделаешь.
Абсолютно логичным с обеих точек зрения любой из этих способов может стать только после упаковки под капот делегату, при этом в случае варианта с заглушкой то только пи заселении самой заглушки константой в сегмент данных.

@titan4ik · 08.07.2020, 15:10 **[ТС]**

Честно говоря, не зная ни парадигм, ни паттеронов, я применял заглушки. Чтобы не было заморочек при отсутствии объектов, то есть при null. И даже придумал для своих объектов спец свойство, которое извещало бы реальный ли это объект или объект заглушка. Свойство инициировалось значением перечисления, содержащего два возможных значения: Empty - пустой объект и Full - наполненный (реальный).
P.S. Необходимость в таком подходе возникла ещё и потому, что эти объекты выполняли роль вложенных в другие объекты - как монетка вкладывается в кошелек. Если с отсутствием монетки ещё можно было смириться (проверкой на null) то с отсутствием кошелька - нельзя (по логике модели), а кошелек не мог существовать без монетки (по логике модели) вот и пришлось придумать пустые объекты (там ещё был и мешок для кошельков - как матрешка). Но всё это как-то не очень природоподобно вышло)

Но работало

@Fulcrum_013 · 08.07.2020, 15:18

Сообщение от titan4ik

Необходимость в таком подходе возникла ещё и потому, что эти объекты выполняли роль вложенных в другие объекты - как монетка вкладывается в кошелек.

Вот с этим надо аккуратно. Подавляющее большинство делегатов обычно пустые а список их на страницу у каждого контрола. При этом дергаются многие чуть ли не на каждом пришедшем от винды сообщении. Т.е. в общем без адресной передачи сообщения получателю (а матрешка именно об этом и говорит) могут быть достаточно серьезные просадки. Хотя если вам микросекунды не критичны то вполне.

@Usaga · 08.07.2020, 15:50

Сообщение от titan4ik

И даже придумал для своих объектов спец свойство, которое извещало бы реальный ли это объект или объект заглушка. Свойство инициировалось значением перечисления, содержащего два возможных значения: Empty - пустой объект и Full - наполненный (реальный).

Вот это, как раз, выглядит весьма криво. У вас и заглушка есть и проверка осталась. Т.е. совместили всё самое плохое от обоих подходов.

@titan4ik · 08.07.2020, 16:20 **[ТС]**

В моем случае - вроде не особо криво было. Не беду углубляться детали. Там важно было, чтобы все сущности были - даже в случае отсутствия реальной монетки (или реального кошелька). А потом были обработки по нужным полям (свойствам) всех монеток во всех кошельках. И на этапе обработки почти не важно - реальная монетка или пустая. Не было там проверки на null или на Empty. Проверка на Empty была только в одном виде обработки (когда считалось сколько реальных монеток в каждом кошельке) - так что, вроде, ничего страшного. Главное, что обеспечивалось наличие всех кошельков и что в каждом кошельке хоть одна монетка есть (может Empty).
К сожалению или к счастью, c# позволяет одно и то же реализовать множеством способов. Для опытного программиста - это счастье (он выбирает близкий к оптимальному вариант). Для неопытного - головная боль (трудно понять что лучше - можно откровенный бред насоздавать - код всё стерпит и даже может работать).

Новые блоги и статьи Все статьи Все блоги /
сукцессия 30. Фосфорный и азотный замки по "честному" закону лимитирования Либиха anaschu 16.07.2026 Основные достижения за последние дни 1. Механизм отложенного высвобождения фосфора Добавлен специальный пул для медленного разложения меланизированных гиф ЕСМ Реализована разная скорость. . .	Запрет пометки на удаление и отмены проведения Maks 16.07.2026 Алгоритм из решения ниже реализован на нетиповом документе "ПутевойЛист" разработанного в КА2. Задача: запретить помечать на удаление и отменять проведения путевого листа при условии, если он сдан. . .	Как надо было делать правильно - вообще не слушать ИИ, его дело - текст. Hrethgir 15.07.2026 А вообще надо было делать не так, чтобы не исправлять ошибку https:/ / www. cyberforum. ru/ blogs/ 223907/ 10996. html , правильно было : удалил кнопку, а потом добавил её. Всё это стресс конечно. Почему?. . .	Знаете, от чего появляется стресс? kumehtar 15.07.2026 Стресс появляется оттого, что вы, зная как поступить правильно, делаете наоборот. Ларри Уингет
Нас бьют, а мы крепчаем? Какая чушь! kumehtar 15.07.2026 Вот это вот бытующее мнение, что человек меняется только под действием проблем, всегда считал вредоносным. Поверь, от проблем у людей появляются не изменения, а нервное расстройство и ПТСР. А. . .	сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .

@titan4ik Заблокирован

	Сравнение скорости вызова делегата без проверки на null и с проверкой 07.07.2020, 12:08. Показов 2344. Ответов 28 Метки нет (Все метки) Рекомендуется всегда использовать вызов делегата с проверкой на null del?.Invoke(); (del - экземпляр делегата) Допустим, нужно сделать миллион итераций в цикле с вызовом делегата в теле цикла. Не внесет ли проверка на null существенной задержки по времени исполнения? Я сейчас проверил (в режиме отладки с пом точек остановки) - практически никакой разницы не заметил. Это нормально? То есть, всегда использовать вызов с проверкой? 0

@titan4ik Заблокирован
	08.07.2020, 15:10 [ТС]
	Честно говоря, не зная ни парадигм, ни паттеронов, я применял заглушки. Чтобы не было заморочек при отсутствии объектов, то есть при null. И даже придумал для своих объектов спец свойство, которое извещало бы реальный ли это объект или объект заглушка. Свойство инициировалось значением перечисления, содержащего два возможных значения: Empty - пустой объект и Full - наполненный (реальный). P.S. Необходимость в таком подходе возникла ещё и потому, что эти объекты выполняли роль вложенных в другие объекты - как монетка вкладывается в кошелек. Если с отсутствием монетки ещё можно было смириться (проверкой на null) то с отсутствием кошелька - нельзя (по логике модели), а кошелек не мог существовать без монетки (по логике модели) вот и пришлось придумать пустые объекты (там ещё был и мешок для кошельков - как матрешка). Но всё это как-то не очень природоподобно вышло) Но работало 0

@titan4ik Заблокирован
	08.07.2020, 16:20 [ТС]
	В моем случае - вроде не особо криво было. Не беду углубляться детали. Там важно было, чтобы все сущности были - даже в случае отсутствия реальной монетки (или реального кошелька). А потом были обработки по нужным полям (свойствам) всех монеток во всех кошельках. И на этапе обработки почти не важно - реальная монетка или пустая. Не было там проверки на null или на Empty. Проверка на Empty была только в одном виде обработки (когда считалось сколько реальных монеток в каждом кошельке) - так что, вроде, ничего страшного. Главное, что обеспечивалось наличие всех кошельков и что в каждом кошельке хоть одна монетка есть (может Empty). К сожалению или к счастью, c# позволяет одно и то же реализовать множеством способов. Для опытного программиста - это счастье (он выбирает близкий к оптимальному вариант). Для неопытного - головная боль (трудно понять что лучше - можно откровенный бред насоздавать - код всё стерпит и даже может работать). 0