Is this slow WPF TextBlock performance expected?
Asked Answered
D

3

19

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.

Disjunct answered 17/3, 2010 at 19:19 Comment(5)
In WPF binding is not exactly the way you did it by the way.Eskimo
I didn't post the code for the version that used binding (and also the MVVM pattern). I figured this version would be even lighter weight and makes for a better example.Disjunct
The vast majority of CPU cycles should be burned on rendering here. But do use a profiler to make sure. Here's a review of your very poky graphics hardware: pcgamingcorner.com/wordpress/?p=820Affidavit
I know the graphics card is terrible, but the problem is that it's faster than what I would have available in the real (embedded) product. I'll have to grab the profiler.Disjunct
You were right, according to Visual Profiler, almost all of the CPU time is in the Rendering thread... is there something even lighter weight than TextBlock that I could use instead?Disjunct
L
45

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.

Label answered 18/3, 2010 at 20:11 Comment(1)
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!Disjunct
P
4

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.

Penmanship answered 17/3, 2010 at 21:15 Comment(2)
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.Disjunct
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.Penmanship
S
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.

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.

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

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

Good luck!

Setser answered 1/2, 2011 at 19:14 Comment(1)
Thanks for your input. We were able to get by with a newer, dual core Atom. It drives two displays with real-time, vector charting and several frequently updating TextBlocks w/ few issues. WPF4's cached composition helped a lot with the charting. Running on Windows 7 with Aero disabled helped a lot too. We have about 1-3% steady state CPU loading and the UI is very responsive. Animations are definitely stuttery compared to my Core i7/nVidia GPU laptop but the user experience doesn't suffer much.Disjunct

© 2022 - 2024 — McMap. All rights reserved.