这个慢WPF TextBlock性能预期吗?

I am doing some benchmarking to determine if I can use WPF for a new product. However, early performance results are disappointing. I made a quick app that uses data binding to display a bunch of random text inside of a list box every 100 ms and it was eating up ~15% CPU. So I made another quick app that skipped the data binding/data template scheme and does nothing but update 10 TextBlocks that are inside of a ListBox every 100 ms (the actual product wouldn't require 100 ms updates, more like 500 ms max, but this is a stress test). I'm still seeing ~5-10% CPU usage. Why is this so high? Is it because of all the garbage strings?

我正在做一些基准测试，以确定我是否可以使用WPF来开发新产品。然而，早期的表现令人失望。我做了一个快速的应用，它使用数据绑定，每100毫秒在列表框中显示一堆随机的文本，它消耗了大约15%的CPU。所以我做了另一个快速应用，跳过了数据绑定/数据模板方案，每100毫秒更新一个列表框内的10个文本块(实际的产品不需要100毫秒更新，最多500毫秒，但这是一个压力测试)。我仍然看到大约5-10%的CPU使用率。为什么这么高?是因为所有的垃圾字符串吗?

Here's the XAML for the version that doesn't use binding:

这是不使用绑定的版本的XAML:

<Grid>
    <ListBox x:Name="numericsListBox">
        <ListBox.Resources>
            <Style TargetType="TextBlock">
                <Setter Property="FontSize" Value="48"/>
                <Setter Property="Width" Value="300"/>
            </Style>
        </ListBox.Resources>

        <TextBlock/>
        <TextBlock/>
        <TextBlock/>
        <TextBlock/>
        <TextBlock/>
        <TextBlock/>
        <TextBlock/>
        <TextBlock/>
        <TextBlock/>
        <TextBlock/>
    </ListBox>
</Grid>

Here's the code behind:

背后的代码:

public partial class Window1 : Window
{
    private int _count = 0;

    public Window1()
    {
        InitializeComponent();
    }

    private void OnLoad(object sender, RoutedEventArgs e)
    {
        var t = new DispatcherTimer(TimeSpan.FromSeconds(0.1), DispatcherPriority.Normal, UpdateNumerics, Dispatcher);
        t.Start();
    }

    private void UpdateNumerics(object sender, EventArgs e)
    {
        ++_count;
        foreach (object textBlock in numericsListBox.Items)
        {
            var t = textBlock as TextBlock;
            if (t != null)
                t.Text = _count.ToString();
        }
    }
}

That consumes ~5-10% CPU according to Task Manager, or up to about 20% of one of the cores! Any ideas for a better way to quickly render text?

根据任务管理器，这将消耗大约5-10%的CPU，或多达其中一个内核的20% !有没有更好的快速渲染文本的方法?

My computer: XP SP3, 2.26 GHz Core 2 Duo, 4 GB RAM, Intel 4500 HD integrated graphics. And that is an order of magnitude beefier than the hardware I'd need to develop for in the real product.

我的电脑:XP SP3, 2.26 GHz Core 2 Duo, 4gb RAM, Intel 4500高清集成图形。这个数量级比我在实际产品中需要开发的硬件要大。

3 个解决方案

#1

Is this slow TextBlock performance normal?

这个慢文本块的性能正常吗?

No. Such slow TextBlock performance is definitely not normal. My experience has been TextBlocks are much faster than that.

不。如此缓慢的文本块性能绝对不正常。我的经验是，文本块要快得多。

I ran several tests using the code you posted, leaving the update interval at 0.1s and varying the hardware and number of TextBlocks. Here is what I found:

我使用您发布的代码运行了几个测试，将更新间隔保留为0.1秒，并更改了硬件和文本块的数量。以下是我的发现:

 10 TextBlocks, 2.16GHz Core 2 Duo, Radeon 4100 GPU:     CPU Usage "0%"
 10 TextBlocks, 2.16GHz Core 2 Duo, Software rendering:  CPU Usage 1%
100 TextBlocks, 2.16GHz Core 2 Duo, Radeon 4100 GPU:     CPU Usage 8%
100 TextBlocks, 2.16GHz Core 2 Duo, Software rendering:  CPU Usage 18%
 10 TextBlocks, 200MHz Pentium Pro, Software rendering:  CPU Usage 35%
 10 TextBlocks, 200MHz Pentium Pro, No rendering:        CPU Usage 7%

Every one of these tests suggests that WPF is approximately 10x as fast as your measurements indicate. If your code is as simple as it appears, my suspicion would be that there is something strange going in with your GPU or DirectX drivers.

每一个测试都表明WPF的速度大约是测量值的10倍。如果您的代码看起来很简单，那么我怀疑您的GPU或DirectX驱动程序中有一些奇怪的东西。

Note that for the 100 TextBlock tests I had to make three changes: Adding 90 TextBlocks, setting the ItemsPanel to a WrapPanel to get the data in columns, and reducing the TextBlock width to get everything to fit on screen.

请注意，对于100个TextBlock测试，我必须做三个更改:添加90个TextBlock，将ItemsPanel设置为WrapPanel以获取列中的数据，以及减少TextBlock的宽度以使所有内容都适合屏幕。

My test on the 200MHz Pentium Pro is probably the most relevant to your embedded hardware. If your application updates 10 TextBlocks every 0.5s you can expect to use approximately 3% of the CPU for the update and redraw on a 200MHz CPU.

我对200MHz奔腾Pro的测试可能与您的嵌入式硬件最相关。如果您的应用程序每0.5秒更新10个文本块，那么您可以使用大约3%的CPU进行更新并重新绘制200MHz的CPU。

What if I want to make it even faster?

如果我想让它更快呢?

Using a list of data-bound TextBlocks is very convenient but WPF also provides lower-level mechanisms that can be used when you need absolute maximum performance.

使用数据绑定的文本块列表非常方便，但是WPF还提供了更低级的机制，当您需要绝对最大性能时可以使用这些机制。

A WPF TextBlock actually contains a formatted document not just a string, so it is a very complex data structure. It is quite simple to write your own TrivialTextBlock control which has a string parameter and simply draws it using the inherited TextElement properties (such as FontSize, FontWeight, etc). This is usually not done because TextBlock is fast enough for almost all purposes.

一个WPF文本块实际上包含一个格式化的文档，而不只是一个字符串，所以它是一个非常复杂的数据结构。编写具有字符串参数的TrivialTextBlock控件并使用继承的TextElement属性(如FontSize、FontWeight等)绘制它非常简单。这通常不会实现，因为TextBlock的速度足以满足几乎所有的用途。

Another consideration is that every time you change the text in a TextBlock, WPF recomputes the layout. Unlike older technologies, the content of a WPF TextBlock can very easily change the layout of your UI. So the text must be remeasured and reformatted every time you change it. Creating the aforementioned TrivialTextBlock control can speed this up as well by fixing the control size and thereby avoiding layout passes.

另一个要考虑的问题是，每次修改文本块中的文本时，WPF都会重新计算布局。与旧技术不同，WPF TextBlock的内容可以很容易地改变UI的布局。因此，每次修改文本时，都必须重新测量并重新格式化。创建前面提到的TrivialTextBlock控件可以通过修复控制大小并避免布局通过来加快这一过程。

A third consideration is that WPF's text formatter has advanced typography features, supporting such things as kerning, bidirectional text, ligatures, unicode features, custom font weights, etc. To get absolute maximum performance in WPF you can bypass the text formatter entirely and draw your text as a series of images. This requires about 20 lines of XAML and about 40 lines of C# code.

第三个考虑是WPF的文本格式化器具有高级的排版功能，支持诸如kerning、双向文本、拼接、unicode特性、自定义字体权值等。要在WPF中获得绝对的最大性能，您可以完全绕过文本格式化器，将文本绘制成一系列图像。这需要大约20行XAML和大约40行c#代码。

All of these optimizations are possible, but in your case I wouldn't bother with them: Doing it to save a mere 3% CPU usage is probably not worth it.

所有这些优化都是可能的，但是在您的例子中，我不会为它们费心:这样做只节省3%的CPU使用率可能不值得。

#2

There is a lot one can do wrong in WPF, as far as performance is concerned. Lot of people approach it like a win forms application, html web page, or some hybrid attack on developing the application and because of this there are a lot of bad evaluations of WPF.

就性能而言，WPF中有很多地方是可以出错的。很多人喜欢用win forms应用程序、html web页面或开发应用程序的混合攻击，因此WPF有很多不好的评估。

I understand that you are trying to do performance testing to see if a WPF can work for your platform and a good example of how to get your WPF application control to perform for the type of load you are expecting can be found at the below link.

我理解您正在尝试进行性能测试，以查看WPF是否适用于您的平台，以及如何让您的WPF应用程序控制对您期望的负载类型执行的一个很好的示例可以在下面的链接中找到。

http://msdn.microsoft.com/en-us/magazine/dd483292.aspx

Petzold guides you through the process of optimizing an items control to render optimally for the load of data being displayed on the UI.

Petzold将指导您优化项控件的过程，以最佳地呈现UI上显示的数据负载。

To do a fair test I would write a sample application that deals with a sample of the data you are going to be dealing with, and then test the performance of that code. There are a large number of optimizations that can be applied to make a WPF application scream and use less CPU, but they all depend on your application and how it is representing your data.

为了做一个公平的测试，我将编写一个示例应用程序来处理将要处理的数据的示例，然后测试代码的性能。有大量的优化可用于使WPF应用程序尖叫和使用更少的CPU，但它们都取决于应用程序及其表示数据的方式。

Hope this helps.

希望这个有帮助。

#3

I would only use WPF for a new product if you are certain your deployment hardware is quite good. Practically speaking, I think a dedicated graphics card is a minimum requirement.

如果您确定您的部署硬件相当不错，那么我将只对新产品使用WPF。实际上，我认为专用显卡是最低要求。

My team selected WPF for a project targeted at an Atom processor platform because the integrated GMA 500 graphics claimed WPF render Tier 2. However, for some reason the performance of the GMA 500 is very slow and we turned hardware rendering off to get better performance. Even then, the Atom platform is underpowered for reasonable performance. I advise not using WPF if netbooks or anything with Intel Atom is part of your customer base.

我的团队为一个针对Atom处理器平台的项目选择了WPF，因为集成的GMA 500图形声称WPF渲染层2。然而，由于某些原因，GMA 500的性能非常慢，我们关闭了硬件渲染以获得更好的性能。即便如此，Atom平台在性能上仍然不够强大。如果上网本或任何与英特尔Atom有关的东西是您的客户基础，我建议您不要使用WPF。

Here is a link to a question I have open on the performance of WPF on GMA 500.

这里有一个关于WPF在GMA 500上的性能问题的链接。

As Rob Perkins suggests, you may be better off with Silverlight 4 for better performance.

正如罗布·帕金斯所建议的那样，为了更好的表现，你最好使用Silverlight 4。

Good luck!

好运！

#1