asp.net-mvc MVC 中的 ViewBag 与 ViewData 性能差异？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/5078996/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
ViewBag vs ViewData performance difference in MVC?
提问by user169867
I know that ViewData and ViewBag both use the same backing data and that neither are as good as using strongly typed models in most cases. However when choosing between the two is the dynamic nature of ViewBag slower than using ViewData?
我知道 ViewData 和 ViewBag 都使用相同的支持数据，并且在大多数情况下都没有使用强类型模型那么好。但是，在两者之间进行选择时，ViewBag 的动态特性是否比使用 ViewData 慢？
回答by Andras Zoltan
Okay - my initial answer basically said 'no' - time for a bit of a u-turn.
好的 - 我最初的回答基本上是“不” - 是时候掉头了。
It shouldbe 'no' in a perfect dynamic world - but upon closer inspection it would appear that there will either be no difference (accounting for JIT magic) or it mightbe ever-so-slightly slower, although not enough to warrant not using it (I certainly am).
在一个完美的动态世界中，它应该是“否”——但经过仔细检查，似乎没有区别（考虑到 JIT 魔法），或者它可能会稍微慢一点，尽管不足以保证不使用它（我当然是）。
In theory if properly implemented, the ViewBag would ultimately outperform the use of the ViewData dictionary because the binding of the expressions (e.g. ViewBag.Foo) is very well cached across the different CallSites that the compiler will generate (reflect a method that does a read or write to the ViewBagand you'll see what I mean).
理论上，如果正确实现，ViewBag 最终将优于使用 ViewData 字典，因为表达式的绑定（例如ViewBag.Foo）在编译器将生成的不同CallSite之间缓存得非常好（反映执行读取或写入的方法）到ViewBag，你会明白我的意思）。
The caching layers of the DLR are well documented(if a little difficult to understand once you get in depth) but basically the runtime does its best to 'remember' where a given value instance is once its bound it - for example via a Set or Get statement.
DLR 的缓存层有很好的文档记录（如果深入了解后会有点难以理解），但基本上运行时会尽力“记住”给定值实例一旦绑定它的位置 - 例如通过 Set 或获取声明。
BUTThe caching, its use and effectiveness, is entirely dependent upon the underlying implementations of classes/interfaces such as DynamicObject, IDynamicMetaObjectProvideretc; as well as the end-result of the Get/Set expression binding.
但是缓存、它的使用和有效性完全取决于类/接口的底层实现，例如DynamicObject、IDynamicMetaObjectProvider等；以及 Get/Set 表达式绑定的最终结果。
In the case of the MVC internal DynamicViewDataDictionary class - it ultimately ends up binding to this:
在 MVC 内部 DynamicViewDataDictionary 类的情况下 - 它最终绑定到这个：
public override bool TryGetMember(GetMemberBinder binder, out object result)
{
result = this.ViewData[binder.Name];
return true;
}
For var a = ViewBag.Foo
为了 var a = ViewBag.Foo
And
和
public override bool TrySetMember(SetMemberBinder binder, object value)
{
this.ViewData[binder.Name] = value;
return true;
}
For ViewBag.Foo = Bar;
为了 ViewBag.Foo = Bar;
In other words - the statements are effectively being rewritten to wrappers around the dictionary indexer.
换句话说 - 这些语句被有效地重写为围绕字典索引器的包装器。
Because of that, there's certainly no way it could be faster than doing it yourself.
因此，肯定没有办法比自己做更快。
Were ViewDatato feed off of ViewBag, instead of the other way around, and had ViewBagthen been implemented with even something like ExpandoObject, then it might be a different story - as the dynamic implementation of ExpandoObjectis much more intelligent and the caching rules it employs allow for some pretty cool runtime optimisations.
被ViewData养活的关ViewBag周围，而不是其他的方式，并已ViewBag然后被用甚至像来实现ExpandoObject，那么它可能是一个不同的故事-作为动态执行ExpandoObject更加智能和缓存规则，它采用允许一些漂亮很酷的运行时优化。
In Conclusion
综上所述
(thanks to Shawn McLean for suggesting one was needed!)
（感谢 Shawn McLean 建议需要一个！）
ViewBag will be slower than ViewData; but probably not enough to warrant concern.
ViewBag 会比 ViewData 慢；但可能不足以引起关注。
回答by Jakub Konecki
I haven't done any test but my gut feel is that in real world scenarios the difference is just negligible. You will probably access it a few times on each page and a few CPU cycles won't make any difference. One can find bigger performance improvements in other places.
我没有做过任何测试，但我的直觉是，在现实世界的场景中，差异可以忽略不计。您可能会在每个页面上访问它几次，并且几个 CPU 周期不会产生任何影响。人们可以在其他地方找到更大的性能改进。
