的ElementName与RelativeResource？ [英] ElementName vs. RelativeResource?

问题描述

以下的TextBlocks绑定的是什么成本更高的性能：

What of the following TextBlocks' Bindings costs more performance:

<Window  
  x:Name="Me"
  x:Class="MainWindow"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
  xmlns:src="clr-namespace:WpfApplication1" 
  Title="MainWindow">
  <StackPanel>
    <TextBlock Text="{Binding Title, ElementName=Me}"/>
    <TextBlock Text="{Binding Title, RelativeSource={RelativeSource AncestorType={x:Type src:MainWindow}}}"/>
  </StackPanel>    
</Window>

我相信当的TextBlocks是有许多兄弟姐妹和祖先高嵌套级别我的问题可能会采取不同的。

I am sure my question might take different when the TextBlocks are in a high nesting level having many siblings and ancestors.

（仅基于个人的想法，我可能是错在每一个特定的一个！）

(based on personal thoughts only, I might be wrong in each particular one!):

• 的ElementName

• ElementName:

• 可以搜索和当前元素比较多的控制，直通其所有的子女，兄弟姐妹，叔叔和舅舅很大的祖先，包括（或许还有所有注册名称的哈希表？）


• 获得一个名称控制比调用的GetType 应该花费更少的性能属性。


• 比较字符串的比较比类型，尤其是当你知道大多数控件甚至没有自己的名称一套便宜。

• Might search and compare current element to more control, thru all its children, siblings, uncles and great uncles including ancestors (maybe there is a HashTable of all the registered names?)
• Getting a Name property of a control should cost less performance than calling GetType.
• Comparing a string is cheaper than comparing types, especially when you know that most of the controls don't even have their Name set.

FindAncestor

FindAncestor:

• 只会重复直通的祖先，而不是siblingls'叔叔'，'堂兄弟'等。


• 最有可能使用的GetType 来确定的祖先类型;的GetType成本更高的性能，然后一个简单的名称属性getter（也许DPS们有什么不同？）

• Will only iterate thru ancestors, not siblingls 'uncles', 'cousins' etc.
• Most likely uses GetType to determine ancestor type; GetType costs more performance then a simple Name property getter (maybe DPs are different?)

推荐答案

这通常是一个可怕的想法，试图通过争论，你认为会更快回答这样的事情。远东更好地构建一个实验来衡量它。

It's usually a terrible idea to try to answer this sort of thing by arguing about which you think will be faster. Far better to construct an experiment to measure it.

我修改您的设置一点 - 我把相关的XAML成用户控件，自用户控件名称属性$ C>不具有标题属性。然后我写了一些code创建控件的新实例，并将其添加到用户界面，并使用秒表来衡量，构建并加载所需的时间。 （我只是构建用户控件之前开始计时，我停止用户控制提高其加载事件之后。）

I modified your setup a little - I put the relevant Xaml into a UserControl, and bound to the Name property since UserControl doesn't have a Title property. I then wrote some code to create a new instance of the control and add it to the UI, and used the Stopwatch to measure the time taken to construct and load it. (I start the timing just before constructing the user control, and I stop just after the user control raises its Loaded event.)

我运行此code一 DispatcherTimer 20次第二，所以我可以采取很多的测量在减少实验误差的希望。为了减少由于调试和诊断code扭曲，我在发布版本中运行，我只计算和反复2000完成后打印的平均值。

I run this code from a DispatcherTimer 20 times a second so I can take lots of measurements in the hope of reducing experimental error. To minimize distortions due to debugging and diagnostic code, I'm running in a Release build, and I only calculate and print the average after 2000 iterations have completed.

在2000次迭代，在的ElementName 办法平均值887us。

After 2000 iterations, the ElementName approach averages 887us.

2000年以后的迭代中，的RelativeSource 办法平均值959us。

After 2000 iterations, the RelativeSource approach averages 959us.

所以的ElementName 是，在这个特殊的实验中，超过的RelativeSource 稍快。加载一个简单的用户控件只是一个电网和一个的TextBlock 那里只有一个命名元素，在的ElementName 方法看起来采取的时间92％加载的的RelativeSource 办法花费。

So ElementName is, in this particular experiment, slightly quicker than RelativeSource. Loading a trivial UserControl with just a Grid and one TextBlock where there's only one named element, the ElementName approach looks to take 92% of the time to load that the RelativeSource approach takes.

当然，我在这里测量一个小的，人为的例子。该方法的ElementName的表现可能会有所不同的基础上有多少命名的元素都在范围内。并有可能成为可能产生在真实情形完全不同的结果的其他非预期的因素。因此，我建议在实际应用的上下文中执行类似的测量，如果你想获得更好的画面。

Of course, I'm measuring a small, artificial example here. The performance of the ElementName approach might vary based on how many named elements are in scope. And there may be other unanticipated factors that might produce completely different results in real scenarios. So I would recommend performing similar measurements in the context of a real application if you want to get a better picture.

我反复实验与10的TextBlocks，而不是1 的ElementName 然后平均2020us而的RelativeSource 办法均2073us ，再次超过2000迭代两个测试。古怪，有一个小的差别在这里，不只是在相对而言的，但在绝对数量 - 单元素示例显示的72us，其中该十元件的例子表明53us的差的差

I repeated the experiment with 10 TextBlocks instead of 1. ElementName then averaged 2020us while the RelativeSource approach averaged 2073us, again over 2000 iterations for both tests. Weirdly, there's a smaller difference here, not just in relative terms, but in absolute terms - the one-element examples showed a difference of 72us, where the ten-element examples showed a difference of 53us.

我开始怀疑我运行我的主要机器上我的测试，而不是一个用尽可能少的东西尽可能谨慎配置以减少噪声造成更多的可变性。

I'm starting to suspect that I'm causing more variability by running my tests on my main machine, rather than one carefully configured with as little stuff as possible to minimize noise.

还有一个变化：仍与10绑定的文本块，我增加了10多个空，未绑定，命名为文本块到用户控件。这里的想法是引进更多的东西命名为 - 的ElementName 现在已在11个命名的东西找到一个命名的项目。平均为的ElementName 现在2775us。这些额外的10命名的元素的RelativeSource 办法在3041us就出来了。

One more variation: still with 10 bound text blocks, I added ten more empty, unbound, named text blocks to the user control. The idea here was to introduce more named things - ElementName now has to locate a named item within 11 named things. The average for ElementName is now 2775us. The RelativeSource approach with these extra 10 named elements came out at 3041us.

此外，我怀疑变异我的台式机就在这里 - 这似乎不可思议了的RelativeSource 已比本来应该更多地<$ c中的场景进行显著恶化这里$ C>的ElementName 的优势。

Again, I suspect variability on my desktop machine here - it seems weird that RelativeSource has performed significantly worse here than in the scenario that should have been more to ElementName's advantage.

不管怎样，有什么的确实的似乎相当清楚的是，这里装载的成本更为敏感元件的数量比是你使用的绑定风格。这里显然是一个小的优势，以的ElementName 但足够小（有足够怪异的结果）投缔结，这是一定会更快的有效性的怀疑。

Anyway, what does seem reasonably clear is that the cost of loading here is far more sensitive to the number of elements than it is to which style of binding you use. There is apparently a small advantage to ElementName but small enough (and with weird enough results) to cast suspicion on the validity of concluding that it is necessarily faster.

因此​​，我们可以构建更仔细的实验​​，以获得更好的画面。但在我看来，如果一个普通的计算机上运行时，你不能决定性地证明在性能上的差异显著，那么它的基本时间争论这是更快的浪费。

So we could construct more careful experiments to get a better picture. But in my view, if you can't conclusively demonstrate a significant difference in performance when running on an ordinary computer, then it's basically a waste of time arguing about which is quicker.

所以在最后：性能是错误的东西在这里重点关注。挑取使得更可读code。

So in conclusion: performance is the wrong thing to focus on here. Pick whichever makes for more readable code.

这篇关于的ElementName与RelativeResource？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！