ИМХО. Проверка на нулевые значения почти никогда не станет узким местом для производительности вашего приложения. (И в одном случае из миллиона, где это важно, вы найдете его в своем профилировщике и удалите этот один случай).
Другой вопрос, который должен возникнуть у вас в голове: «Неужели бросить новое NullReferenceException () действительно лучший способ справиться с ошибкой?» Зачастую вы можете справиться с этим лучше (даже если только предоставить лучший отчет об ошибках пользователю и / или себе для целей отладки). Во многих случаях код может корректно обрабатывать значения NULL, что делает ненужным, чтобы это вообще было ошибкой.
редактировать
Чтобы ответить на ваши изменения: нулевые проверки действительно не занимают много времени. Затраты на простой вызов метода будут в десятки, если не в сотни раз больше, чем нулевая проверка. Единственное место, где нулевая проверка будет иметь какое-либо существенное значение, - это большой плотный цикл, где вы делаете совсем немного. Такая ситуация случается не очень часто - обычно вы проверяете нулевое значение, а затем делаете что-то относительно дорогое с этой ссылкой.
Нет ситуации, когда сбой или сбой - это хорошая вещь. Всегда лучше «замедлить работу приложения» с нулевыми проверками, чем аварийно завершить работу и потерять данные вашего клиента.
Так что не преждевременно оптимизируйте свой код. Хорошо напишите это, чтобы его можно было поддерживать и поддерживать, а затем профиль , чтобы увидеть узкие места. Я программировал в течение 28 лет, был очень либеральным с нулевыми проверками, и никогда не обнаружил, что нулевая проверка была причиной проблемы с производительностью. Обычно это такие вещи, как выполнение большого количества ненужной работы в цикле, использование алгоритма O (n ^ 3), где возможен подход O (n ^ 2), неспособность кешировать дорогостоящие для вычисления значения и т. Д.