views:

682

answers:

2

Hi,

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?

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

<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?

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.

A: 

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.

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.

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.

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.

Hope this helps.

Don Pavlik
Well one of the main selling points, for me, with WPF is that it allows you to work at a higher level of abstraction, hopefully leading to much improved productivity. But if (presumably) simple things like this lead to high CPU loading, and you need to dig in to get it to perform well, then that productivity advantage starts to wear off. I'll have to do some more research it seems.
Ben Schoepke
It can lead to improved productivity, but you have to go through a learning curve of what and how to use WPF first. Once you go through that the speed in which you can build an application is quick. I have built a few applications with WPF and currently working on an enterprise level application with WPF and the development time is a lot shorter than it would have been with other platforms and the flexibility that is gained is great.
Don Pavlik
+2  A: 

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:

 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.

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.

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.

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.

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.

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.

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.

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.

Ray Burns
Wow, that was an incredibly helpful and thorough reply, and it really made my day. Thanks Ray.I set up another PC with an Atom CPU running Windows 7. The same program that runs at 5-10% CPU on my workstation runs at 0% CPU on this PC. There is definitely something up with my video card/driver on my workstation. Either that or maybe WPF rendering is just much faster in Windows 7 than XP.Thanks for the tip on TextBlock updates invoking the layout system, I'll definitely keep that in mind.Have a great day!
Ben Schoepke