gpt4 book ai didi

wpf - ElementName vs.RelativeResource?

转载 作者:行者123 更新时间:2023-12-03 14:39:36 25 4
gpt4 key购买 nike

以下哪些 TextBlocks 的绑定(bind)会消耗更多性能:

<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 处于具有许多 sibling 和祖先的高嵌套级别时,我的问题可能会有所不同。

注意事项

(仅基于个人想法,我可能在每个特定的地方都错了!):
  • ElementName :
  • 可能会搜索和比较当前元素以进行更多控制,通过它的所有子元素、 sibling 、叔叔和叔叔,包括祖先(也许有一个所有已注册名称的哈希表?)
  • 获取 Name控件的属性应该比调用 GetType 花费更少的性能。 .
  • 比较字符串比比较类型便宜,尤其是当您知道大多数控件甚至没有它们的 Name 时放。
  • FindAncestor :
  • 只会遍历祖先,而不是 sibling “叔叔”、“堂兄弟”等。
  • 最有可能使用 GetType确定祖先类型; GetType 比简单的 Name 花费更多的性能。属性 getter (也许 DP 不同?)
  • 最佳答案

    通过争论你认为哪个会更快来尝试回答这类问题通常是一个糟糕的主意。最好构建一个实验来测量它。

    我稍微修改了您的设置 - 我将相关的 Xaml 放入 UserControl,并绑定(bind)到 Name属性自 UserControl没有 Title属性(property)。然后我编写了一些代码来创建控件的新实例并将其添加到 UI,并使用 Stopwatch测量构建和加载它所花费的时间。 (我在构建用户控件之前开始计时,并在用户控件引发其 Loaded 事件后停止。)

    我从 DispatcherTimer 运行此代码每秒 20 次,因此我可以进行大量测量,以期减少实验误差。为了最大限度地减少由于调试和诊断代码造成的失真,我在 Release 版本中运行,我只在 2000 次迭代完成后计算和打印平均值。

    在 2000 次迭代后,ElementName接近平均887us。

    在 2000 次迭代后,RelativeSource接近平均959us。

    所以ElementName在这个特定的实验中,比 RelativeSource 稍微快一点.加载一个琐碎的UserControl只需一个 Grid和一个 TextBlock其中只有一个命名元素,ElementName方法看起来需要 92% 的时间来加载 RelativeSource方法采取。

    当然,我在这里测量一个小的人工示例。 ElementName 方法的性能可能会根据范围内命名元素的数量而有所不同。并且可能还有其他意想不到的因素可能会在实际场景中产生完全不同的结果。因此,如果您想获得更好的图像,我建议您在实际应用程序的上下文中执行类似的测量。

    我用 10 个 TextBlocks 而不是 1 个重复实验。ElementName然后平均 2020us 而 RelativeSource方法平均为 2073us,两次测试再次超过 2000 次迭代。奇怪的是,这里有一个更小的差异,不仅仅是相对而言,而是在绝对方面——单元素示例显示出 72us 的差异,而十元素示例显示出 53us 的差异。

    我开始怀疑我在我的主机上运行我的测试会导致更多的可变性,而不是用尽可能少的东西仔细配置以最小化噪音。

    另一种变化:仍然有 10 个绑定(bind)文本 block ,我向用户控件添加了另外 10 个空的、未绑定(bind)的命名文本 block 。这里的想法是引入更多命名的东西 - ElementName现在必须在 11 个命名事物中找到一个命名项目。 ElementName 的平均值现在是2775us。 RelativeSource这些额外的 10 个命名元素的方法出现在 3041us。

    再次,我怀疑我的台式机上的可变性 - RelativeSource 似乎很奇怪在这里的表现明显比在 ElementName 的情况下要差得多。的优势。

    无论如何,似乎相当清楚的是,这里的加载成本对元素的数量比对您使用的绑定(bind)样式更敏感。 ElementName 显然有一个小优势但足够小(并且结果足够奇怪),足以让人怀疑得出它必然更快的结论的有效性。

    所以我们可以构建更仔细的实验​​来获得更好的画面。但在我看来,如果你不能最终证明在普通计算机上运行时性能上有显着差异,那么争论哪个更快基本上是浪费时间。

    所以总而言之:性能是错误的关注点。选择更易读的代码。

    关于wpf - ElementName vs.RelativeResource?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/4317097/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com