Разница в производительности ViewBag и ViewData в MVC?

Хорошо - мой первоначальный ответ в основном был отрицательным - пора сделать небольшой поворот.

Это должно быть «нет» в идеальном динамическом мире, но при более внимательном рассмотрении может показаться, что либо не будет никакой разницы (с учетом JIT-магии), либо может быть чуть-чуть медленнее, хотя и не настолько, чтобы не использовать его (конечно, я).

Теоретически при правильной реализации ViewBag в конечном итоге превзойдет использование словаря ViewData, потому что привязка выражений (например, ViewBag.Foo) очень хорошо кэшируется в разных CallSite, которые компилятор сгенерирует (отражают метод, выполняющий чтение или запись в ViewBag, и вы поймете, что я имею в виду).

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

НО Кэширование, его использование и эффективность полностью зависят от базовых реализаций классов / интерфейсов, таких как DynamicObject, IDynamicMetaObjectProvider и т. д .; а также конечный результат привязки выражения Get / Set.

В случае внутреннего класса MVC DynamicViewDataDictionary - в конечном итоге он привязывается к этому:

public override bool TryGetMember(GetMemberBinder binder, out object result)
{
  result = this.ViewData[binder.Name];
  return true;
}

Для var a = ViewBag.Foo

И

public override bool TrySetMember(SetMemberBinder binder, object value)
{
  this.ViewData[binder.Name] = value;
  return true;
}

Для ViewBag.Foo = Bar;

Другими словами, операторы фактически переписываются в оболочки индексатора словаря.

Из-за этого, конечно, нет способа быть быстрее, чем делать это самому.

Были ViewData подпитываться от ViewBag, а не наоборот, и тогда ViewBag был реализован даже с чем-то вроде _ 10_, тогда это может быть другая история - как динамическая реализация _ 11_ намного умнее, а правила кэширования, которые он использует, позволяют провести довольно крутые оптимизации времени выполнения.

В заключении

(спасибо Шону Маклину за то, что он предложил!)

ViewBag будет медленнее, чем ViewData; но, вероятно, этого недостаточно, чтобы вызывать беспокойство.

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