ContructorInfo.Invoke против делегата - PullRequest
4 голосов
/ 25 февраля 2011

Я видел несколько вопросов здесь, в SO, о том, как заставить делегата создать объект вместо использования ConstructorInfo.Invoke.

Вот пример: Использование делегата для вызова конструктора .

Я просто хочу знать, почему? Если это с точки зрения производительности, почему делегат быстрее?

Обновление

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

Но что происходит, когда конструктор вызывается через делегата? То же самое, что и при выполнении var a = new XXX() или что-то еще?

ConstructorInfo.Invoke() делает то же самое, что и new XXX()? (Не обращайте внимания на любые проверки)

При использовании Activator.CreateInstance() делайте это примерно так же, как и Constructor.Invoke() (кроме поиска и проверки типов).

Полагаю, мой вопрос сводится к следующему: могут ли объекты создаваться разными способами (например, разными инструкциями IL) или все методы упоминания используют одни и те же инструкции, но с разными видами проверок перед фактическим созданием?

1 Ответ

3 голосов
/ 25 февраля 2011

Несколько причин:

  • В разных местах у вас есть для предоставления делегата. Если что-то требует Func<T>, вы не можете просто дать ему ConstructorInfo.
  • Это безопасный тип - вы можете гарантировать, какой тип будет создан (или, по крайней мере, совместимый тип), и вы знаете, какие аргументы требуются (если есть). Вызывая ConstructorInfo.Invoke, каждый раз, когда вы вызываете его, во время выполнения есть много ошибок, а не только когда создается делегат.
  • Это быстрее, потому что вся проверка (доступ, аргументы) и т.д. выполняется один раз при создании делегата, а не каждый раз, когда вызывается метод ConstructorInfo.Invoke.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...