Comparison of Grid control performance and wpfgrid performance on the WPF Platform

Comparison of Grid control performance and wpfgrid performance on the WPF Platform

The first official version of WPF has been released for 10 years, and we have almost started the development of XAML at the same time. Even after years of building, we still try to improve: Have we really created efficient and flexible controls? I have not found any introduction to the Performance Comparison of excellent WPF tables in other places. I have only a small number of discussions about controls that have not existed for a long time. This new benchmark is an attempt to discover our advantages and disadvantages in some of the more popular controls in the market.

Environment

This benchmark was created in June 2016 and uses the following Grid control. (The latest trial version we use)

• DataGrid (part of PresentationFramework. dll) under System. Windows. Controls)
• C1FlexGrid 4.4.0.20162.514 (ComponentOne WPF)
• C1DataGrid 4.4.0.20162.514 (ComponentOne WPF Version)
• XamDataGrid v16.1.16.1.20161.1000 (WPF Controls-Infragistics)
• GridControl v15.2.15.2.10.0 (WPF Controls | DevExpress)
• SfDataGrid 14.1400.0.41 (Syncfusion Essential Studio for WPF)
• RadGridView 2016.2.503.40 (Telerik WPF Controls | ui wpf Version)
• DataGridControl v5.9.5.9.16204.15420 (Xceed DataGrid for WPF)

This benchmark runs in the ENVY-23 All-in-One Desktop environment and has the following configurations.

Intel i7 quad-core CPU at @ 3.10 GHz

8 GB RAM

NVIDIA GeForce GT 630 M display adapter, Full HD (1920x1080) resolution

Windows 10 Pro 64-bit OS

All Grid controls are set to the same size and default appearance.

Test Application

Our benchmark application allows you to select and run a separate test or allow all tests to run one by one. You can select the number of times of the same test run to obtain the average value in the result.

This can reduce the impact of other aspects, such as the interaction between the operating system and other applications. All the results displayed here will be run 10 times. The following is the application window.

Benchmarking Application Window

 

If you want to analyze a specified use case, it is very convenient to run a separate test. Note: You need to compare different test cases. Do not change the size of the form during test run. The actual view size will affect the performance, just as the large screen will consume more time and resources such as virtual controls to layout and thus affect other events.

This application writes the test results to the Excel file in the working folder. If you need a more detailed log file, you can remove the comment output to TraceListener from the App. xmal. cs file.

The most interesting part here is how to test the running time of complex operations when the asynchronous UI is updated. After several experiments, we found that we were thinking of the most appropriate method to obtain the accurate time when the Girder UI was updated. The complete source code has been attached. You can try it. We will be glad to receive feedback that you think we can improve in some ways.

We do not include the binary version of any controls. If you want to run the application, you need to download the trial version of our WPF version and the use version of other controls involved in the comparison. They all have a 30-day free trial, which is not a problem.

Benchmark

We select ListCollectionView as the data source and fill it with the business object defined below.

public class Customer :  INotifyPropertyChanged, IEditableObject{    public int ID { get; set;}    public string Name { get;}    public string Country { get;}    public int CountryID { get; set;}    public bool Active { get; set;}    public string First { get; set;}    public string Last { get; set;}    public DateTime Hired { get; set;}    public double Weight { get; set;}    public string Father { get;}    public string Brother { get;}    public string Cousin { get;}}

It provides 12 columns of different types.

We tried to set the same conditions for the Grid. For some controls, we changed some settings to meet this requirement.

• Automatically generate Columns
• Fixed column width
• Allow adding a new row at the bottom of a new row
• Hide group and search panel
• Editable Cell

Follow the steps below for each benchmark

1. Remove all UIS created in the previous test. Call the GC. Collect and GC. WaitForPendingFinalizers methods so that garbage collection does not affect the next test;

2. initialize the timer for the next test and Stopwatch;

3. perform the test as required;

4. measure the total time and calculate the average result;

5. record the results.

The following describes the implementation details of a specified benchmark.

Create controls and load data in reference 1.

This benchmark creates a user control that contains a Grid for testing. Insert it into the visualization tree and fill in the data. The only trouble is that the Xceed DataGridControl created with the Code does not work properly. Therefore, you will see that the append application creates it using XAML.

Benchmark 2: Reload data to an existing control

The ItemsSource of the DataGrid is set to null as the benchmark, which is used to clear data and automatically generate columns. Set ItemsSource to a new ListCollectionView. In the code, it is like the following (for all tested controls)

public override void Load(IList data)        {            if (data == null)            {                _grid.ItemsSource = null;            }            else            {                _grid.ItemsSource = new ListCollectionView(data);            }        }

Benchmark 3: arrange a single column

We try to reduce the custom code in the test, so we use the IcollectionView interface in most cases.

public override void Sort(bool ascending){     ICollectionView dataView = CollectionViewSource.GetDefaultView(_grid.ItemsSource);     dataView.SortDescriptions.Clear();     dataView.SortDescriptions.Add(new SortDescription("ID", ascending ? 

       ListSortDirection.Ascending : ListSortDirection.Descending));}

This is very standard, and we hope that every Grid should be built in for support. However, the SfDataGrid of Syncfusion is not supported, so we need to sort the table by using the SfDataGrid. SortDescriptions attribute.

We encountered a problem in testing the XamDataGrid of Infragistics. He can use ICollectionView to sort data, but it is slow when big data is encountered. When we want to get the comparison results of all controls, we finally implement it through FieldLayout. SortedFields.

For reference 4 and 5, scroll 100 rows to scroll the entire form.

We think this can simulate end user interaction well in the test, but we have not found a good way. We may find the scroll bar in the visualization tree and Scroll it. However, the relevant code also affects the performance. Therefore, we decided to keep the specific line into the view. All grids have ScrollIntoView or similar solutions to solve this problem.

Test result initialization loading time

To avoid calculating the number of times of JIT compilation and XAML parsing in all tests, we start from a separate test of each control, which is almost the same as benchmark 1. When you run it for the first time throughout the application life cycle, you can find that it is different from the next running. It is measured as the startup time of the application, which is critical to WPF. The following test shows the results of almost identical data specifications.

Initialization loading time

Fixed width reference

The following are the results of 1,000, 10,000, and 100,000 data sources.

Result of 1000 rows of data with a fixed column width

Result of 10,000 rows of data with a fixed column width

Result of 100,000 rows of data with a fixed column width

Automatic column width reference

After running the test of fixed column width, we decided to compare their performance in automatic column width. This test is only applicable to four types of grids with real-time automatic column width. I want to get a comparison result under the best condition of each Grid. Therefore, we select the default SizeToHeader option for the DataGrid of MS and the RadGridView of Telerik, the default AutoStar option for C1DataGrid, And the XamDataGrid of Infragistics. default FieldLength. initialAuto option.

Why don't we perform this test on all controls? Our C1FlexGrid, DevExpress GridControl, and Xceed DataGridControl do not support instant column width calculation. Obviously, this is the sacrifice made by the designer to focus on the control performance. All the controls above support calling methods to automatically calculate the column width, but you need to call the appropriate method at the right time. This makes it difficult to measure the overall performance, and you cannot determine that the test results are fully dependent on the performance. Therefore, our comparison does not contain those controls.

On the contrary, the SfDataGrid control of Syncfusion does not have an option similar to the automatic column width calculation of the MS DataGrid and other controls, but because the applicable options become slow when loading big data, it cannot be compared with other controls. So we also discharged it in this test. The following are the results of testing data sources that contain 1,000, 10,000, and 100,000 data records. (The same benchmark as fixed column width)

 

The result of 1000 rows of data under the automatic width.

The result of 10,000 rows of data under the automatic width.

Under automatic width100,000The result of the row data.

Some conditions

Our results differ from previous discussions about the performance of the WPF Grid. Obviously, the current controls have the visualization capability and can process a large amount of data, if you plan to select a Grid for your application, our results are a good reference.

We did not test other scenarios, such as grouping, filtering, and column data visualization. Also, performance does not represent all. You may like a widget for some other reasons. For example, usability, XAML customization, and number of embedded features.

When I made these benchmarks, I read a lot of information about control comparison, and I was very impressed that all WPFGrid can be divided into the following two categories:

• Performance-based Grid is not included in the test of automatic column width calculation.
• Focuses on ease of use and XAML application.

Our WPF version contains the above two controls, so you can select one that best suits your needs. For more information, refer to the appendix for comparison of detailed functions of C1FlexGrid, C1DataGrid and MS DataGrid.

In the end, during the entire benchmark comparison process, I can't help but summarize our own controls. So we get another useful information: The C1DataGrid control of version 2016 v2 is faster than the previous version 35% or later.

• Download WPFGridsBenchmark source code (19 KB zip)
• Download 1000 rows of data test results (38.5 KB xls)
• Download 10,000 rows of data test results (38.5 KB xls)
• Download 100,000 rows of data test results (38.5 KB xls)
• Download the C1FlexGrid, C1DataGrid, and MS DataGrid feature comparison table (17.7KB xlsx)