Performance optimization under windows CE (.NET CF)

[tms4000]

I'm using TeeChart on an embedded Windows CE device.

I'm displaying a bar chart with 6 series and 32 data points in each series.

When I update the data, I'm finding the it takes almost 2 seconds of CPU time on the UI thread for TeeChart to process the paint messages.

I need help optimizing this as the 2 seconds interferes with other UI updates I need to perform on the screen in a timely manner.

Are there any settings that have a large effect on screen paint performance that I should be wary of using?

When I get new data I'm flushing out the existing series like so:

foreach (Series objSeries in chartTank.Series)
{
objSeries.Clear();
}

Is there another way to do this that's more performant?

[tms4000]

Incidentally,
I have

chartTank.Aspect.View3D = false;

and
Series.Dark3D = false for all series.

[Christopher]

Are there any settings that have a large effect on screen paint performance that I should be wary of using?

Which series type are you using? As a first step, try using a FastLine series type, the best performing series type, to see what difference that makes.

[tms4000]

I'm using the barchart series type..


Is there a way to update the series data by only changing the values that change? Instead of clearing the series and repopulating them? If I took this approach would there be a performance gain?

[Christopher]

I'm using the barchart series type..


Is there a way to update the series data by only changing the values that change? Instead of clearing the series and repopulating them? If I took this approach would there be a performance gain?

No, I don't think so, as the whole chart will still have to be repainted. The bottle neck here isn't in TeeChart's internal calculations for positioning, but is in the painting of objects to the screen. Given that any change to the position of a series point means repainting the whole chart (there is no alternative here), then I don't think there are any gains to be made here.

Did you try using the FastLine series to see if that made a difference?

Another idea is to turn off all the gradients in the Bar series, as these take much longer to paint than solid colours.

[tms4000]

I ran timing with the bar series and again with the same data but using the fastline series. I don't see any performance difference.

What I'm seeing is if there is a pending update to the TeeChart control, I'm getting an approximate 500ms delay when there is an attempt to marshall code back to the form's ui thread.

[tms4000]

I don't think I'm using gradients in my chart, I don't have any code that explicitly turns them on. Are gradients enabled by default? Is there code I should be using the explicitly turn them off?

[tms4000]

I setup a BeforeDraw and AfterDraw event handler and have more accurate timing as a result.

It takes roughly 650ms to draw the bar chart.

[Christopher]

I don't think I'm using gradients in my chart, I don't have any code that explicitly turns them on. Are gradients enabled by default? Is there code I should be using the explicitly turn them off?

Yes, gradients are enabled by default - you could turn them off with:

Code: Select all

      tChart1.Panel.Gradient.Visible = false;
      tChart1.Walls.Back.Gradient.Visible = false;
      bar.Gradient.Visible = false;

[Christopher]

I setup a BeforeDraw and AfterDraw event handler and have more accurate timing as a result.

It takes roughly 650ms to draw the bar chart.

You said 2 seconds ... so if it takes 650ms to draw the chart, where are the other 1350ms being spent?

[tms4000]

I no longer think the 2 second number is accurate. I think 650ms is the correct timing. It's reproducible and fairly consistent, and because I timed it using the beforedraw and afterdraw events, I think it is the most accurate.

Still 650ms is a long time to hog up the ui thread.

[Christopher]

I no longer think the 2 second number is accurate. I think 650ms is the correct timing. It's reproducible and fairly consistent, and because I timed it using the beforedraw and afterdraw events, I think it is the most accurate.

Still 650ms is a long time to hog up the ui thread.

Which version of the compact framework are you using? I read here:

We are happy to announce that we will be including the .NET Compact Framework 3.9 in Windows Embedded Compact 2013, as part of its upcoming release. We have made major updates in this version of the .NET Compact Framework, which deliver benefits in startup time, application responsiveness and memory utilization. You should see significantly better performance characteristics of your applications on both x86 and ARM devices, running Windows Embedded Compact 2013.

This suggests to me that versions of the .NET CF before v3.9 suffered from significantly less performance characteristics.

[tms4000]

We are currently using .NET CF version 3.5

[Christopher]

We are currently using .NET CF version 3.5

Are you using an emulator or a physical device for these tests?

If you're using an emulator, it is possible for you to try the emulator of CF.NET 3.9?

If you're using a physical device, do you see its physical memory/chip characteristics together with a sub-optimized version of CF.NET as being a factor here?

If you were using an emulator it would be great to know exactly which one so I could have a close look at the issue this end.

[tms4000]

We are using a physical device.

When it was design we didn't anticipate performance issues like this. If I got you detail specs on what hardware is running, would you be able to determine where the bottleneck is?