Тест производительности нулевого указателя

Тесты на недействительность, вероятно, будут эквивалентны простым тестам «равно 0». Они очень, очень дешевы — сотни на кадр должны быть совершенно незначительными, если у вас частота кадров не исчисляется миллионами :)

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

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

Разборка оператора if (x == null) дает:

00000030  cmp         qword ptr [rsp+20h],0
00000036  jne         000000000000004A

т.е. проверка реализована как простое целочисленное сравнение значения указателя.

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

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

Вероятно, субъективно, но проверка на нуль эквивалентна проверке на равенство нулю и такая же быстрая. Так что я не думаю, что вам стоит беспокоиться об этом.

В равной степени - если у вас нет проблем с производительностью, зачем с этим играть.

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

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

if([condition])
{
  Foo();
}
else
{
  Bar();
}

Если, скажем, [condition] включает локальную переменную _obj (в вашем случае _obj == null) - вы можете заменить что-то вроде этого (но будьте очень осторожны с проблемами потоковой передачи):

private Action _logic;
private object _obj;
public Object Obj {
  get { return Obj; }
  set {
    _obj=value;
    if([condition])
      _logic = () => Foo();
    else
      _logic = () => Bar();
  }
}

И теперь в любом коде, где вы ранее отметили [condition] для выполнения ветвления, вы теперь просто делаете:

_logic();

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

Существуют и другие варианты этого, чаще всего таблицы поиска функций, полученные из значения, вместо выбора ветви кода на основе проверки на равенство (именно так могут быть реализованы большие операторы switch/case — делегаты добавляются к Dictionary с ключом проверяемое перечисление/значение - что позволяет избежать многократных проверок значения).

В конечном счете, однако, без должной осмотрительности профилирования (до и после, конечно), проведение таких оптимизаций принципиально бессмысленно.

Никаких проблем (производительность или что-то еще) с if (x == null).

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