元素名称与相对资源? [英] ElementName vs. RelativeResource?

问题描述

以下哪些 TextBlock 的绑定会增加性能:

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>

当 TextBlock 处于具有许多兄弟姐妹和祖先的高嵌套级别时，我确信我的问题可能会有所不同.

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:

• 可能会搜索和比较当前元素以获得更多控制，通过其所有孩子、兄弟姐妹、叔叔和叔叔，包括祖先(也许有所有注册名称的哈希表?)
• 获取控件的 Name 属性的性能应该低于调用 GetType 的性能.
• 比较字符串比比较类型成本更低，尤其是当您知道大多数控件甚至没有设置Name 时.

• 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:

• 只会遍历祖先，而不是兄弟姐妹叔叔"、表兄弟"等.
• 最有可能使用GetType来确定祖先类型；GetType 比简单的 Name 属性 getter 花费更高的性能(也许 DP 不同?)

• 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 放入 UserControl，并绑定到 Name 属性，因为 UserControl 没有 Title 属性.然后我编写了一些代码来创建控件的新实例并将其添加到 UI，并使用 Stopwatch 来测量构建和加载它所花费的时间.(我在构建用户控件之前开始计时，并在用户控件引发其 Loaded 事件后停止.)

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.)

我每秒从 DispatcherTimer 运行这段代码 20 次，这样我就可以进行大量测量，希望能减少实验误差.为了最大限度地减少由于调试和诊断代码造成的失真，我在发布版本中运行，并且我只在 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 稍微快一些.加载一个简单的 UserControl，只有一个 Grid 和一个 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 个 TextBlock 而不是 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 个绑定文本块，我向用户控件添加了另外十个空的、未绑定的、命名的文本块.这里的想法是引入更多命名的东西 - 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 在这里的表现明显比 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.

所以总而言之:在这里关注性能是错误的.选择更易读的代码.

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

这篇关于元素名称与相对资源?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！