The DataGridView is used everywhere – both in ASP.net apps as well as WinForms apps. A quick google search will reveal the scale of users affected by the slow refresh rate on the DataGridView control.  How the data is displayed is dictated by a property called the Display Mode. The Display Mode that most datagridview users opt for is the Bound mode.

An object-bound datagridview

Object binding refers to the ability to bind a control to a custom data type (your domain objects). In pre-object binding days, one would bind a control directly to the raw data (e.g. an int CustomerID and a string CustomerName retrieved from the datasource). This was a cumbersome approach since most of the data could logically be grouped into custom data types (e.g. Customer). The User Interface was mainly interested in displaying the domain types (e.g. Customer) and less interested in native data types such as ints and strings. This led to the development of object-binding as an alternative to older raw data-binding.

A typical datagridview application that uses object binding will involve the following steps:

  1. Fetching Data (usually using ADO.NET and a DataReader/DataTable/DataSet combination).
  2. Storing the fetched data in a local collection (typically an IList<T> where T represents your custom domain object e.g. IList<Customer>).
  3. Converting the IList<Customer> to a BindingList<Customer>
  4. Binding the BindingList to the datagridview

For a detailed walkthrough of custom object binding to a datagridview, see this MSDN magazine article.

Bound Display Mode

For object bound DGVs (datagridviews), the ‘Bound’ mode is the most commonly used display mode. In this mode, the datagridview control is automatically bound to the source of the data – and any changes to the source of the data cause refreshes of the various UI elements of the grid (columns, rows etc.). This offers a degree of convenience that is appealing, at least for small volumes of data. This Bound mode kicks into effect whenever you set the Datasource property on the  datagridview as shown in the snippet below.

Code Snippet
  1. // Define your BindingList
  2.           BindingList<object> bindableDataSource = new BindingList<object>();
  3.  
  4.           // Add some data to the bindingList
  5.           BindingList<object> list = CreateData();
  6.           foreach (object item in list)
  7.           {
  8.               bindableDataSource.Add(item);
  9.           }
  10.           // This actually ‘binds’ the gridview to the BindingList. Any changes to the BindingList from here on affect the gridview.
  11.           // For e.g. – The ‘bound’ gridview would refresh its layout every time a new item is added to this BindingList
  12.           dataGridView1.DataSource = bindableDataSource;

The Problem with Bound display mode

The first indications of problems with the bound mode are visible as soon as you start adding additional items to the source list (while the grid is bound to it). Note that it is possible to add additional items without binding the grid – and then performing the binding step at the very end – as shown in the snippet above. However, even with this approach, at some point, you may need to add/delete items from the source list – causing unnecessary refreshes. More serious problems with the DataGridView start manifesting themselves as the size of the bound collection grows. For larger sets of data, this problem grows to unacceptable response times.

Enter Virtual Mode

By default, most datagridview developers use a Display mode called Bound. In this display mode, the data in the grid is automatically bound to the data in the datasource. This means that the grid view control handles all aspects of fetching the data as well as displaying the data. While this offers convenience, it is the main reason for slower display performance on the DGV. Fortunately, there is another display mode available to address this problem. This mode is known as the virtual display mode. In this display mode, instead of being bound to the entire datasource, the grid is essentially bound to a small subset (a cached portion) of the datasource. This small subset is the set of data should match the data that is visible on the grid (the exact amount of data is under the programmer’s control). Whenever a user wants to see more data (scrolls the grid), that data is fetched from the datasource, placed into cache – and returned to the grid from the cache. This way, only a small amount of data is ever bound to the grid – and even that only through a memory based cache.  This alleviates a lot of issues with the Windows DataGridView – including slow UI refreshes, locked UIs etc.

Quick Conversion from bound to virtual (full source code at the end of this post)

In your source code, if you are using the bound display mode (happens by default if you set the ‘datasource property) you will be setting the datasource property on your gridview somewhere – e.g.

Code Snippet
  1. this.dataGridView1.DataSource = _customers;

Instead of setting this datasource property, what you will need to do is initialize the grid to use virtual mode. This is shown in the snippet below (full source code included at the end of this post).

Code Snippet
  1. private void InitializeGrid()
  2.         {
  3.             // Enable virtual mode.
  4.             this.dataGridView1.VirtualMode = true;
  5.  
  6.             // Connect the virtual-mode events to event handlers.
  7.             this.dataGridView1.CellValueNeeded += new
  8.                 DataGridViewCellValueEventHandler(dataGridView1_CellValueNeeded);

The actual dataGridView1_CellValueNeeded event is where the event to request more data is handled.  The included source code below provides a quick implementation of the virtual display mode – which should work for simple use cases. For a full walkthrough on a virtual mode implementation, see MSDN.

What if the Virtual Mode is still sluggish?

If the performance of virtual mode is still sluggish for your data (if you have several thousands of rows of data), chances are you need to look elsewhere. There are several 3rd party grid controls on the market – including Infragistics, Syncfusion and Telerik. One such grid that I have worked with extensively is Syncfusion’s Grid Control. On my project, we were handling several hundred MBs of data in the grid – with refreshes occurring in real-time or near real-time (i.e. no sluggishness).  A performance comparison is detailed in an earlier post.

In addition to the speed, you also get a host of features that I like to call Grid on Steroids features. These include nested grids (which make it possible to efficiently display hierarchical data), multiple column sorts (which isn’t available out of the box in Windows DataGridView – but can be custom built), pivot tables and more.

Summary

If you are witnessing slow rendering (sluggish rendering) of your datagridview in your WinForms (or ASP.NET ) application, chances are you are using automatic binding (bound display mode). Chances are that you will experience a significant benefit from trying the virtual display mode built into the gridview. This display mode binds to a smaller, cached subset of the full data, allowing quicker UI refreshes. The sample attached here shows a grid using the bound mode and another grid using virtual mode (both with identical 10000 rows of customer data). Even with this simple sample of a few 100 KBs of data, a noticeable difference can be seen (by visual inspection) when one tries to scroll down the grid to view more rows. The refresh rate of the virtual mode grid clearly wins out.  If you find the virtual mode also insufficient for your application’s volume of data, you might need something like the syncfusion grid.

Source Code

Download Full Solution

About the Author

  Anuj Varma is a Microsoft .NET architect specializing in high-performance applications. His specific expertise in the .NET framework architecture as well as 3rd party controls (such as Syncfusion) built around the framework,  makes him a sought after performance expert for .NET applications. Most recently, he has worked on an ASP.NET revamp of dell.com as well as a WinForms app used to map Ocean floors (Petrel). Both these applications were built with performance (UI performance as well as Data Access Layer performance) as a key driver. In addition to n-Tier apps, Anuj works hands-on in the WCF and Azure arena to bring performance to existing SOA apps. Anuj’s personal blog can be found here – anujvarma.com/blog/technology,

Anuj holds professional certifications in Google Cloud, AWS as well as certifications in Docker and App Performance Tools such as New Relic. He specializes in Cloud Security, Data Encryption and Container Technologies.

Initial Consultation

Anuj Varma – who has written posts on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

 Twitter Linkedin