How to: Improve Grid Performance

• Jan 28, 2024
• 6 minutes to read

This article describes the following ASPxGridView performance issues:

• ASPxGridView Takes a Long Time to Render
• ASPxGridView Data Callbacks Are Slow

The difference between DevExpress and standard controls is extensive, but it should not strongly affect performance. If you notice significant slowness, you can research ASPxGridView performance on the server and client as follows:

• Measure Performance on the Server
• Measure Performance on the Client

If the entire page’s rendering speed is slow, consider the following common recommendations: How To: Improve Page Rendering Speed.

ASPxGridView Takes a Long Time to Render

DevExpress ASP.NET Web Forms Grid and Data Editors use HTML table-based rendering. In the following cases ASPxGridView renders a large number of table elements on a page that can cause performance issues.

The Control Displays Many Rows

• When ASPxGridView is bound to more than several hundred data rows and the SettingsPager.Mode property is set to ShowAllRecords, the render time can increase.

• When you call the ExpandAll() method or set the AutoExpandAllGroups property to true, the grid expands all group rows and the control renders a significant amount of additional markup.

You can reduce the amount of HTML markup that is generated in the following ways:

• Display a pager and decrease the page size.
• Enable virtual scrolling.
• Enable endless paging.

Master Grid Displays Many Detail Grids

When you call the DetailRows.ExpandAllRows method, the master grid expands every detail row, renders a detail grid in a row, and binds the grid to its data source. If a master grid has many rows, the method call can reduce page performance due to the table-based structure of these controls.

To speed up grid render, decrease the page size or enable virtual scrolling to limit the number of rows displayed in the grid at a time.

Grid Contains Templated Cells

If you implement templates for grid cells, decrease the page size or use virtual scrolling to limit the number of rows displayed within the grid at a time.

In addition, consider the following ideas to improve the grid’s performance in edit mode:

• Use editors in native mode.

• Use the PopupCalendarOwnerID property to share the same calendar for every date editor in the grid.

  <dx:ASPxGridView runat="server" ID="Grid" AutoGenerateColumns="False" DataSourceID="AccessDataSource1" 
      KeyFieldName="OrderID" OnAutoFilterCellEditorInitialize="Grid_AutoFilterCellEditorInitialize"
      OnCellEditorInitialize="Grid_CellEditorInitialize">
      <Columns>
          ...
      </Columns>
      <Settings ShowFilterRow="True" />
  </dx:ASPxGridView>
  
  <dx:ASPxDateEdit runat="server" ID="__ReferenceDateEdit" ClientVisible="false" />
  

  protected void Grid_CellEditorInitialize(object sender, DevExpress.Web.ASPxGridViewEditorEventArgs e) {
      SetupCalendarOwner(e.Editor as ASPxDateEdit);
  }
  protected void Grid_AutoFilterCellEditorInitialize(object sender, DevExpress.Web.ASPxGridViewEditorEventArgs e) {
      SetupCalendarOwner(e.Editor as ASPxDateEdit);
  }
  void SetupCalendarOwner(ASPxDateEdit editor) {
      if(editor == null) return;
      editor.PopupCalendarOwnerID = "__ReferenceDateEdit";
  }
  

• If DataItemTemplate contains an ASPxComboBox bound to a large number of items, enable EnableCallbackMode and CallbackPageSize properties. If your real data source is larger than several thousand records, use the technique from the following demo: Custom Data Binding.

• Enable batch edit mode, which allows users to modify a batch of grid data on the client side without rendering cell templates.

ASPxGridView Data Callbacks Are Slow

ASPxGridView requires the entire data source to correctly manipulate data even if the grid displays only a few rows. For this reason, data manipulation can decrease server performance when a grid is bound to a large data source.

ASPxGridView supports a specific binding mode designed to work with large datasets. In this mode, data-aware operations are executed on the database server side. If, in your application, ASPxGridView operates with a large amount of data, use one of the solutions described in the following topic: Bind Grid View to Large Data (Database Server Mode).

If database server mode is already in use, but performance is still not acceptable, check if the following issues occur in your application.

Data Binding is Implemented Incorrectly

Make sure that your implementation does not initially fetch all data rows at once. You can use an SQL profiler to check.

This situation may occur if you pass a generic list of data, DataTable, or DataSet to the server and call the AsQueryable method to transform this data to an IQueryable object. This technique negates any advantages of server mode since the entire data source is loaded in the server memory. Moreover, transformation can also take additional CPU time.

To resolve this issue, generate a select expression before data is obtained from a database.

Unnecessary DataBind Method Calls

Make sure that there are no unnecessary DataBind method calls within your binding logic. See the following topic for recommendations on how to bind ASPxGridView at runtime: Bind Grid View to Data at Runtime.

Dynamic Settings Are Specified Too Late

Apply dynamic settings, for instance a user’s sort and filter settings, before data is bound in Page.Init or the ASPxGridView.Init event handler. If you use events that fire later in the page life cycle, the grid hierarchy is recreated and rows are re-rendered multiple times.

Enclose a sequence of operations that affect grid appearance or functionality in BeginUpdate() and EndUpdate() method calls to avoid unnecessary render operations.

Row Cache Usage Is Not Optimal

Check if you are using the row cache correctly. Refer to the following topic for more information: Built-in Row Cache.

Measure Performance on the Server

You can measure ASPxGridView performance on the server in the following ways:

• Test your application with a profiler (for instance, dotTrace and AQTime) to determine the code that might be the cause of performance issues.

• Use standard .NET methods to measure application performance speed. For instance, use the Stopwatch class to capture the assumed problematic methods duration.

  Stopwatch sw = System.Diagnostics.Stopwatch.StartNew();
  //some operations
  sw.Stop();
  AddEventLog(String.Format("Page_Load, Time: {0}", sw.Elapsed.TotalMilliseconds));
  
  private void AddEventLog(string eventLog) {
      if (!String.IsNullOrEmpty(eventOrder))
          eventOrder += "<br/>";
      eventOrder += eventLog;
  }
  

• Use SQL Server Profiler or a similar tool for each database engine to check how long it takes to retrieve data at the database level.

Measure Performance on the Client

All popular browsers have profilers that you can use to determine the problematic script. If the issue occurs inside our internal methods, feel free to send us your profiling log and/or a sample project, so that we can check this issue on our side.

Additionally, you can use standard JavaScript methods to measure script loading time.

var start = new Date();

function ge_ControlsInitialized(s, e) {
    var end = new Date();
    var output = document.getElementById("output");
    output.innerHTML = "Loading time (in ms): " + (end - start);
}

<span id="output"></span>

<dx:ASPxGlobalEvents ID="ge" runat="server">
    <ClientSideEvents ControlsInitialized="ge_ControlsInitialized" />
</dx:ASPxGlobalEvents>