Hello to all,
i am using the latest IG Release 2020.2 along with a WPF application.
I had a deeper look at the "Binding High Volume Data" from the WPF Demo application.
500.000 data points are created by default and then are bound to the chart.
On my machine it takes something between 40 and 90 ms.
The demo app is compiled against Framework 4.
I made a new WPF project targeting .NET5, and used exactly the same source as in the demo application.
Now it takes something like 400 to 500ms until the chart chart has finished layouting.
Why is there such a big difference?Is it because of .NET5 or do i miss something with the IG assemblies?I use a series resolution of 1, and i cannot change this. (but i use this in the IG demo and in my .NET 5 sample, so same settings here)
Also i compared to a Framework 4 WinForms app. this is even faster than the WPF app compiled against Framework 4.
We used Framework 4 and IG 2016 so far, which showed a good performance for some kind of realtime charting of sampled data.
For a new project we are using IG2020.2 and .NET5 and we are pretty far away from what we need when it comes to chart performance...
I appreciate any ideas.
Thanks
Thomas
Hello Thomas,
I have been investigating into the performance difference you are seeing between .NET Framework and .NET 5, but I cannot seem to reproduce the behavior you are seeing after extracting the chart from the Binding High Volume Data sample project you referenced and binding it to a data source that creates a large amount of points (500,000). In doing this, I am seeing about the same performance, and at times, slightly better when using .NET5 with the Infragistics NuGet packages, as this is how we are supporting .NET5.
I am unsure why there is such a difference on your machine at the moment, but I would like you to try running the sample projects I am attaching to this post. The output window in Visual Studio will report in milliseconds the amount of time it takes to generate the data source and bind it to the chart. It is worth noting that my tests were made against the latest service release of Infragistics for WPF 20.2, which is specific version 20.2.20202.38.
Regarding the performance difference in Windows Forms and WPF, it is difficult to say why Windows Forms may be faster, but I think this would be different scenario-to-scenario. The reason I believe this is because Windows Forms and WPF have different geometry path rendering techniques, and there are certain geometric shapes that Windows Forms likes better than WPF and vice-versa. A large majority of the code between the XamDataChart and UltraDataChart is shared as well. As a more extreme example of this, consider this forum thread with highly fluctuating data in WPF. This causes performance issues because WPF’s rendering methods simply do not play nice with that type of geometric shape (more detailed information in that thread). The same would not be true of Windows Forms here, though.
Please let me know if you have any other questions or concerns on this matter.
DataChartPerformanceTests.zip
Hello Andrew,
thanks for the answer and the time you spent on it.
we also used the Nuget packages and the latest SR, so versions are the same.
The article with the highly fluctuating data is interesting, since this is what we will see in our application too. data from a sensor of cource including noise.
We are now crosstesting with different machines we have here, even your new example is much slower - 120ms for databinding - compared to the sample from the IG WPF samples...thats really weird.
Thanks Thomas
If you are at the decision of whether to use WPF or Windows Forms for your application regarding the chart, and you are using highly fluctuating data, you will likely want to use Windows Forms UltraDataChart or the “ImmediateLineSeries” from the sample in the other thread. The difference between these two is that the “ImmediateLineSeries” is not something that is directly supported as it was a custom solution given for the fluctuating data behavior in WPF by using a custom series with a custom rendering method.
Regarding the time for the data binding, some time may be saved in the sample projects I have provided you by specifically setting the chart’s DataContext rather than the Windows’ DataContext which is currently being set. There also could be some time being spent because of Visual Studio being run and the debugger being run, and you would likely see some performance increase if you ran without debugging and store the time spent in TextBlocks so that you can see it.