Forums Ultimate UI for Windows Forms
Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
Close
Mike Saltzman
469350
WinGrid Performance Guide
posted

The purpose of this article is to provide some general programming practice guidelines and troubleshooting tips to improve performance when using the UltraWinGrid control. Not all of the tips provided here will apply to every application, but it should help with the most common performance issues a developer is likely to encounter.

Performance

1) Painting

Painting the grid, or any control, on the screen can often be a source of performance issues. This is especially the case when multiple operations are performed on the control in code at run-time, each of which causes the control to be invalidated in whole or in part.
For example, suppose you have code to loop through every row of the grid and update the value in a cell:
 
        private void ultraButton1_Click(object sender, EventArgs e)
        {
            foreach (UltraGridRow row in this.ultraGrid1.Rows)
            {
                row.Cells["Price"].Value = (double)row.Cells["Price"].Value + 1.0;
            }
        }
Each time a cell is updated, some part of the grid will be invalidated and the grid may re-paint itself on the screen many times. In a case like this, you can prevent the grid from painting more than once by disabling the painting before the loop begins and re-enabling it once all operations are complete.  You do this with the BeginUpdate and EndUpdate methods.
 
        private void ultraButton1_Click(object sender, EventArgs e)
        {
            this.ultraGrid1.BeginUpdate();
 
            try
            {
                foreach (UltraGridRow row in this.ultraGrid1.Rows)
                {
                    row.Cells["Price"].Value = (double)row.Cells["Price"].Value + 1.0;
                }
            }
            finally
            {
                this.ultraGrid1.EndUpdate();
            }
        }
Notice that a try…finally block is used here.  This is to make sure that no matter what happens, the grid’s painting always gets turned back on eventually.
Another case, similar to this, is when you are making changes to the grid’s DataSource directly. Most data sources will notify the grid of changes and the grid will do some internal process of these changes, even if it is not painting. You can turn off this internally processing and gain some performance using the SuspendRowSynchronization/ResumeRowSynchronization methods. These methods should always be called inside a block with BeginUpdate and EndUpdate. For example:
 
        private void ultraButton1_Click(object sender, EventArgs e)
        {
            this.ultraGrid1.BeginUpdate();
            this.ultraGrid1.SuspendRowSynchronization();
 
            try
            {
                // Get the DataTable the grid is bound to. This assumes the
                // data source is a DataTable.
                DataTable dt = (DataTable)this.ultraGrid1.DataSource;
 
                foreach (DataRow row in dt.Rows)
                {
                    row["Price"] = (double)row["Price"] + 1.0;
                }
            }
            finally
            {
                this.ultraGrid1.ResumeRowSynchronization();
                this.ultraGrid1.EndUpdate();
            }
        }
 

2) The CellDisplayStyle property.

By default, every cell in the grid uses an Editor to display and edit its value. Editors have a lot of power and flexibility, providing valuelists, color choosers, date dropdown, masking, checkboxes, buttons and many other features. But with all these features come extra overhead and more complex painting. The grid cannot know what features your application will and will not need at run-time, so by default, all features are enabled. However, if you know you will not be using certain features in a column, you can turn some features off using the CellDisplayStyle property. For details on the CellDisplayProperty and the various options available, please refer to the Infragistics Online Help.

3) ValueLists

Another common cause of slowdowns in the grid is the improper use of ValueLists (include ValueList, BindableValueList, UltraCombo, UltraComboEditor,  and UltraDropDown). ValueLists can provide a dropdown list in a cell. But it’s important to realize that the grid will need to search the list quite often, especially if the DataValue/DisplayValue feature is used and the grid needs to translate values into user-friendly display text.
Make sure data types match - If the DataValue values in the ValueList are a different DataType that the values in the actual grid cell, this can cause performance problems for several reasons. First, the grid is going to need to convert the value from one data type to another. Second, this conversion process may result in an Exception. These exceptions will be caught and handled by the grid. But the raising of exceptions takes a large toll on performance, even when those exceptions are caught. So it’s important to make sure that the DataValues in your ValueList are exactly the same data type as the values in the grid.
Make sure every grid cell value exists on the list - Another common ValueList pitfall is when the value in the grid cell does not exist on the list. Suppose, for example, you have a column in the grid with integer values ranging from 1 to 100. Now let’s say there is a ValueList attached to the column with values from 1 to 100. This is fine and, on average, the grid will need to do 50 comparisons to find the matching item on the list for each cell that paints. But now suppose that every cell in the column starts off with a value of 0. In this case, the grid must search all 100 items in every cell that paints before it can determine that the item does not exist on the list. Adding a value of 0 to the ValueList would alleviate this problem.
Binary searching - The UltraDropDown control has the capability of doing binary searching. In order to perform a binary search, the DropDown must keep an internal sorted list of the DisplayValues on the list. This means there is a small performance hit the first time the dropdown is used since it has to build the list. But every search after that will be much faster than a linear search would be. So using UltraDropDown may gain your application a significant performance boost at the cost of a small initial hit. Note that the UltraDropDown control has a property called DropDownSearchMethod, which default to Binary, but can be set to Linear, if you don’t want to use binary searching.
EditAreaDisplayStyle - When you attach an UltraDropDown (or UltraCombo) to a cell and select an item, the appearance of the item is copied into the grid cell. So if you have an image applied to a cell in the dropdown, that image will appear in the cell when the corresponding item is selected. In order to handle this, the DropDown needs to search the list to find the largest image and leave space for that image in the grid cell. This searching of the list can slow down the painting of the grid. So in v6.1 of the UltraDropDown, a new property was added called EditAreaDisplayStyle. By setting this property to DisplayText, you can tell the dropdown that the grid cell does not need to show images based on the selected item. This is an especially good idea if your dropdown is not actually using images.

4) Recursion

The UltraWinGrid drills down into its data source and creates a CurrencyManager for every level. If you bind the grid to a recursive data source, this means that the grid will, by default, create 100 levels of CurrencyManagers. The number 100 is the default of the MaxBandDepth property.
Each level of depth in the data source will increase the number of CurrencyManagers in a logarithmic scale. So the first level of the grid only requires 1 CurrencyManager. The second level requires one CurrencyManager for each row in the first level. The third level of depth requires one CurrencyManager for each row in the second level, and so on. This can quickly add up to a huge usage of memory and make it very difficult for the grid to synchronize its current row with the current Position of the CurrencyManager.
To alleviate this kind of issue, there are serval things you can do.
The first is to set MaxBandDepth to a more reasonable number. Very few users will find it useful to drill down into the data 100 levels deep. They will become lost long before they every reach that point. A value of between 5 and 8 usually gives a good balance between displaying a reasonable depth of data and still having grid that performs well.
The second thing you can do is to set SyncWithCurrencyManager to false. This tells the grid not to synchronize the current row with the current position of the CurrencyManager. This means that if there are other controls in the application bound to the same data source as the grid, changing the grid’s current row will not position the CurrencyManager and thus not update the other controls. But very often, this is not necessary, anyway.
Also, using a BindingSource may also help. See the next section.

5) Use a BindingSource

In Visual Studio 2005 (or more accurately in the DotNet Framework CLR 2.0), some changes were made to the DotNet BindingManager that might cause performance problems with the grid when it is bound directly to a DataTable or DataSet under certain conditions.
Wrapping the grid’s Data Source in a BindingSource corrects these issues. See Infragistics KB article #9280 for more details.

6) Exceptions

As mentioned briefly above (under ValueLists) thrown exceptions can have a big impact on performance, even if those exceptions are caught and handled. So it’s often a good idea to set the Visual Studio IDE to break on all run-time exceptions and reveal any exception that might be occurring. If exceptions are occurring, then where they occur can often provide information on how to avoid them.
 

Memory Usage

If you are concerned about reducing the amount of memory used by the grid, then there are several important things you can do to reduce it. 

1) Don't reference cells unneccessarily - use GetCellValue, instead. 

The grid does not create UltraGridCell objects for every row of data. Cells are only created as neccessary. So whenever possible, you should avoid accessed a cell. For example, suppose your code is using the InitializeRow event of the grid in order to calculate a total. For example:

 
        private void ultraGrid1_InitializeRow(object sender, InitializeRowEventArgs e)
        {
            e.Row.Cells["Total"].Value = (double)e.Row.Cells["Quantity"].Value * (double)e.Row.Cells["Price"].Value;

        }

This code references three cells in each row of the grid, thus creating a lot of objects which are potentially unneccessary. This can be avoided using methods on the row to deal with cell values, rather than the cell objects themselves. Like so:



        private void ultraGrid1_InitializeRow(object sender, InitializeRowEventArgs e)
        {
            UltraGridColumn quantityColumn = e.Row.Band.Columns["Quantity"];
            UltraGridColumn priceColumn = e.Row.Band.Columns["Price"];
            e.Row.Cells["Total"].Value = (double)e.Row.GetCellValue(quantityColumn) * (double)e.Row.GetCellValue(priceColumn);

        }

By using the GetCellValue method, we can eliminate 2 cells per row in this example and save memory. 

2) Re-use Appearances

Another common use for the InitializeRow event is to apply an appearance to a cell based on the Value of that cell. Applying an appearance to a cell requires getting a reference to the UltraGridCell, so that is unavoidable. But you can save memory by re-using the same appearance object for multiple cells. Suppose, for example, that you want to change the ForeColor of a cell to red for negative numbers and black for positive numbers. You might do something like this: 

 
        private void ultraGrid1_InitializeRow(object sender, InitializeRowEventArgs e)
        {
            // Get the value of the Total column.
            UltraGridColumn totalColumn = e.Row.Band.Columns["Total"];
            double total = (double)e.Row.GetCellValue(totalColumn);
 
            if (total < 0)
                e.Row.Cells["Total"].Appearance.ForeColor = Color.Red;
            else
                e.Row.Cells["Total"].Appearance.ForeColor = Color.Black;

        }

This code will create a cell for every row. That is unavoidable, since the cell must be created in order to have an Appearance. The bigger problem here is that the Appearance property on the cell is lazily created. That means that we are not only creating a cell for each row, but a new Appearance object for each row. And since there are only two possible colors, we end up creating a large number of identical appearance objects.

A better way to do this is to create the Appearances we need up front and then re-use the same appearance wherever it is needed.

 
        private void ultraGrid1_InitializeLayout(object sender, Infragistics.Win.UltraWinGrid.InitializeLayoutEventArgs e)
        {
            // Create an appearance for negative values
            Infragistics.Win.Appearance negativeAppearace = e.Layout.Appearances.Add("Negative");
            negativeAppearace.ForeColor = Color.Red;
 
            // Create an appearance for positive values
            Infragistics.Win.Appearance positiveAppearace = e.Layout.Appearances.Add("Positive");
            positiveAppearace.ForeColor = Color.Black;
        }
 
        private void ultraGrid1_InitializeRow(object sender, InitializeRowEventArgs e)
        {
            UltraGrid grid = (UltraGrid)sender;           
 
            // Get the value of the Total column.
            UltraGridColumn totalColumn = e.Row.Band.Columns["Total"];
            double total = (double)e.Row.GetCellValue(totalColumn);
 
            if (total < 0)
                // Use the Negative Appearance already defined in the grid's Appearances collection.
                e.Row.Cells["Total"].Appearance = grid.DisplayLayout.Appearances["Negative"];
            else
                // Use the Positive Appearance already defined in the grid's Appearances collection.
                e.Row.Cells["Total"].Appearance = grid.DisplayLayout.Appearances["Positive"];

        }

Another benefit to this approach is that you can change the appearance everywhere en masse. For example, suppose your users want to use Green instead of Black for positive appearances. You could, at run-time, set the ForeColor of the “Positive” Appearance object, and every cell in the grid that was using that appearance would update automatically.

  • 9364
    posted

    Mike, I remember reading somewhere in this forum about turning off some features of Grid if one does not need it and thereby gaining performance. I thought you had mentioned it in this thread but I do not see to find it here.

    Thanks!

  • 1834
    posted

    Mike,

    In regards to your first point, do BeginUpdate/EndUpdate and/or SuspendRowSynchronization/ResumeRowSynchronization need to be used when just binding the data source to the grid?

    Example:

    try

    {

      DataTable dtTable = myDAO.GetTable();

      ugGrid.BeginUpdate();

      ugGrid.SuspendRowSynchronization();

      ugGrid.DataSource = dtTable;

    }

    catch ....

    finally

    {

      ugGrid.ResumeRowSynchronization();

      ugGrid.EndUpdate();

    }

     

    Just wondering if there's any performance benefit to that approach, or if the control already suspends itself until InitializeLayout and all InitializeRow events have completed.

    Thanks,

    Jamal

  • 17259
    Offline posted in reply to Sundaresan

    Attached

    GetCellValue.zip
  • 1800
    posted

    Good article Mike. We have been doing a lot of analysis of the same kind to determine the overhead w.r.t performance.

    Although it is similar to what we found, it gave us good insights to avoid crucial performance issues.

    Thanks.,