Pre loader

Comparing Performance for a Fifo chart shows direct3 slowest and high quality renderer fastest

Welcome to the SciChart Forums!

  • Please read our Question Asking Guidelines for how to format a good question
  • Some reputation is required to post answers. Get up-voted to avoid the spam filter!
  • We welcome community answers and upvotes. Every Q&A improves SciChart for everyone

WPF Forums | JavaScript Forums | Android Forums | iOS Forums

Answered
1
0

Comparing Performance for a Fifo Chart yields unexplained outcome. Fastest Renderer: high quality renderer. Slowest: direct3d.
My problem is not that they don’t reach the tested performance but that the high quality renderer looks fastest. I would expect direct3d to be the fastest.

Can anyone explain this or possibly find an error in my code or reasoning?

I attach sample code.
First picture is in debug build and the second in release build. In release the software renderers are not so far apart any more but still noticeable.

Explanation of test:

I used the FifoSample from the samples suite and changed it for performance tests.

There are 2 projects. One is the control in WpfControl using SciChart the other one is hosting the control in WpfControlHost. (This setup is only this complicated for testing because it will by my setup later.)

I got the following outcome. Essentially high quality renderer is fastest. Taking less time. Frequency is the highest. Then comes the high performance renderer and finally the direct3d renderer.

What is the test supposed to do (if I didn’t make a mistake!):

The goal is to reach 110.000 Hz sample rate (worker_DoWork.hertz * this._multiplier). Putting in 10 values at once for each series on an iteration round. Iterations try to reach 11.000/sec.

In source code: (method: worker_DoWork)hertz = 11.000 and this._multiplier = 10

Measurements are done by Microsoft StopWatch Class where 1second is documented as = StopWatch.Ticks/StopWatch.Frequency (of Processor).

To switch the renderers I uncomment the sections in UserControl1.xaml and run a test in debug or release build without Visual Studio attached.

Attachments
  • You must to post comments
Best Answer
3
0

I’ve been discussing this issue with Uwe offline as its a big bigger than a forum post can allow. Here are the results of our discussion if anyone else is interested.

Measuring Performance

It is possible to measure the performance of an individual SciChartSurface by using the SciChartPerformanceOverlay control. To use one, declare it like this:

<SciChartSurface x:Name="sciChartSurface">
    <!-- Omitted for brevity -->
</SciChartSurface>

<!-- Declare the SciChartPerformanceOverlay control over the top of a SciChartSurface -->
<SciChart:SciChartPerformanceOverlay TargetSurface="{Binding ElementName=sciChartSurface, Path=.}" Margin="40"/>

This will draw some diagnostics over the top of the chart so you can see actual FPS and UI Thread speed via CompositionTarget.Rendering event.

Drawing speed in DirectX

First up, I ran the sample provided and the overall Frame Rate of the DirectX renderer was approximately 10x the software renderers on my PC (Macbook pro 2012, running Windows 8).

Performance (FPS) with the DirectX renderer…
enter image description here

Performance (FPS) with the High Speed renderer…
enter image description here

As you can see above, DirectX is indeed 10x faster at drawing. However, the problem as Uwe clarified is that DataSeries.Append called in a tight loop is slower when the DirectX renderer is attached, than when the software renderer is attached.

Why is this?

We’re still investigating why this is, but we believe there is some contention between the rendering (UI) thread and the appending (DataSeries.Append) thread.

e.g. if you append very fast single points repeatedly, the fast DirectX renderer consumes the points. Some synchronization logic between the UI and Append threads causes contention.

Slower renderers (software renderers) draw less often therefore there is less contention.

Workarounds

There are two workarounds to increase the overall application performance when appending in a tight loop.

1. Set SciChartSurface.MaxFrameRate

Setting MaxFrameRate caps the high speed of the DirectX renderer. This frees up
resources & reduces contention between the render thread and
DataSeries.Append thread. We found setting MaxFrameRate = 30 was
sufficient to improve speed of appending single points significantly

e.g.

    <!-- Define the SciChartSurface -->
    <SciChart:SciChartSurface MaxFrameRate="30"> 

2. Append in blocks.

By appending in blocks of 100 the overall speed to append data was greatly increased. We made a small change to the codebase to append in blocks of 100 and the overall speed to append improved about 20x.

These workarounds are also recommended at the Performance Tips & Tricks page

Results

The results of applying our two workarounds (MaxFrameRate = 30FPS) and Appending on blocks in 100 can be seen below.

Appending point by point. Time to append 5M points = 29 seconds…
enter image description here

Appending in blocks of 100, and MaxFrameRate=30. Time to append 5M points = 1 second…
enter image description here

  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.

Try SciChart Today

Start a trial and discover why we are the choice
of demanding developers worldwide

Start TrialCase Studies