The following improvements have been made:

• [NEW] Significantly improved cell painting performance. Fixed an error with the grid re-painting the entire row on a notification from a field for which the column is hidden or non-existent.
• [NEW] Improved the Grid’s disposal algorithm. Handling of the situation when a grid can be disposed in the main thread and receive notifications from a non-GUI thread at the same time has been fixed as compared to the previous version.

The following bugs have been fixed:

• [BUG] Fixed an error when a grid smaller than 20 pixels sometimes could generate exceptions on cell painting.
• [BUG] Fixed rendering error when paining merged columns in RTL modе.
• [BUG] Fixed header painting error with freezed columns in RTL mode.
• [BUG] Fixed an error when moved rows stopped receiving notifications from data source when a grid unsubscribed a row from a datasource with drag&drop operations.
• [BUG] Fixed a CheckBoxEditor error when the grid could generate exceptions on partial editor visibility.

The following bug has been fixed:

• [BUG] Fixed a bug where the grid redraw the content of the entire row upon receiving notification from INotifyPropertyChanged interface for missing or hidden column.
• [BUG] Fixed minor bugs in the designer.

The following features have been added:

• [NEW] Added column filter serialization
• [NEW] Reengineered grid designer introducing intuitive and convenient user interface.
• [NEW] Significantly improved grid performance with selection large data volumes.
• [NEW] Overall performance improvement.

The following bugs have been fixed:

• [BUG] Fixed an error with the grid not unsubscribing from objects with composite properties when objects are removed from the grid.
• [BUG] Fixed an error with Dapfor.Net.dll not appearing in the list of available assemblies in Visual Studio.
• [BUG] Fixed an error with Column.Appearance property hiding cell highlighting.
• Minor bug fixes

In most cases programmers use this method without thinking of consequences or its working principle. MSDN documentation says that this method processes messages in queue and when there are no more messages it stops working and passes control to the next code.
In simplified form this method looks as follows:

NativeUnsafeMethods.MSG msg;
while (PeekMessage(out msg))
{
TranslateMessage(ref msg);
DispatchMessage(ref msg);
}

However, we may wonder what happens when application is intensively rendering controls, synchronizing threads and performing other operations in GUI thread? In such situation message queue always contains messages that don’t let method finish its work. As the result, the end user won’t notice the difference in application behavior as Application.DoEvents() will process executing messages, including WM_PAINT messages, i.e. controls will be redrawn and the program will not slow down. However, code execution will stop on Application.DoEvents() method. If there are important operations after this method, they will not be executed until message queue is freed. We have often seen the situation when application was updating stock market prices and in times of high volatility prices were updated with noticeable delays!!!

A simple example of the problem is shown below. Demo application intensively synchronizes threads and paints data. Main GUI thread continuously processes messages (including synchronization messages and WM_PAINT messages). Clicking Start button calls Application.DoEvents() once, and in normal situation it should immediately return control to subsequent code. However, in this example the things are different! This method is followed by MessageBox.Show(…) that doesn’t display anything.
If demo application is fully covered with any other window or collapsed in the taskbar, Windows stops sending WM_PAINT messages and as the result of it message queue becomes empty, Application.DoEvents() method stops and MessageBox.Show(…) is executed.

Download DoEventsExample.zip

Therefore, before using Application.DoEvents() programmers should look at application architecture and ask themselves whether this method is really necessary. If application code really requires Application.DoEvents(), we have added Dapfor.Net.Editors.MessageQueueHelper class starting from version 2.8.4. This class has similar behavior but it also supports maximum execution time limit. If there are no more messages in queue, MessageQueueHelper also stops and passes control to the subsequent code.

The following features have been added:

• [NEW] Greatly improved the reliability and responsiveness of the grid when the CPU is heavily loaded.

The following bugs have been fixed:

• [BUG] Fixed a bug in the column configurator which in some cases does not allow reordering of visible columns.
• [BUG] Fixed a bug where merged columns were drawn with artifacts.
• [BUG] Fixed a bug when the grid incorrectly draws cells if there are simultaneously visible grouped rows and child header.
• [BUG] Fixed a bug when the grid incorrectly displays a vertical scrollbar if there are simultaneously visible grouped rows and child header.
• Minor bug fixes

Even the best performing component can be hindered by incorrect use. Below we provide practical recommendations on what should be used or avoided in application programming. Following the tips below you will be able to create applications with the same
efficiency as this demo application. We also provide source codes for this example to show how easy it is.

• It is supposed that programmers already know general principles of application design. Nevertheless, we shall provide  some useful links for better understanding of .Net environment and tools for writing managed code: Writing Faster Managed Code: Know What Things Cost
• It is necessary to pay attention to grid characteristics in different working modes, to evaluate data volume to be  displayed and to find a relevant chart for better understanding of grid use.
• Use ThreadSafeBindingList<T> instead of BindingList<T> for the following reasons:1. BindingList<T> has poor implementation when working with objects that implement INotifyPropertyChanged interface.  Hereyou can find more information on BindingList<T> performance issues.  Use ThreadSafeBindingList<T> instead, as it doesn’t allow BindingList<T> to subscribe to events of objects that it contains.2. Another reason to use ThreadSafeBindingList<T> instead of BindingList<T> is related to implementation of  MulticastDelegate used in events. With one subscriber, this delegate consumes minimum memory resources, but when there are two  or more subscribers, it creates an internal subscriber collection that increases memory consumption dramatically. The grid always subscribes  to objects that implement INotifyPropertyChanged interface and BindingList<T> is the second subscriber.
• If BindingList<T> is used together with objects implementing INotifyPropertyChanged interface, it is  better to avoid firing notifications with non-existent data object properties. It is mainly required because when a binding  list receives such notification it checks whether the firing object has the specified property. If the firing object doesn’t  have such property, the BindingList<T> generates ListChanged event specifying Reset reason and forcing the grid to rebuild all its contents.
• Avoid using INotifyPropertyChanged interface, unless it is required. If the object doesn’t change at run-time, it is better not to use this interface to save memory and CPU resources.
• Add data to the end of collection (List<T>, BindingList<T>, ThreadSafeBindingList<T> etc). Otherwise, internal implementation of indexed collections will move and re-index all data starting from the newly added index.
• Avoid adding data to a binding list with more than 10 000 items when the grid is sorted. Stop sorting to improve performance.  However, if you need to add large amounts of data in real-time to the beginning of the grid, it’s better to use the following:

  grid.Sort.Enabled = false;
  grid.DataSource = _datasource_;

  //Add a single object to the beginning of the grid
  grid.Nodes.Insert(0, _new_object_);
  
  //Add a single object to the beginning of the binding list
  IBindingList bl = ...;
  bl.Insert(0, _new_object_);

• Although the grid is thread-safe with INotifyPropertyChanged and IBindingList interfaces, use the GUI thread  to work with it. This is mainly important for adding large data volumes. Some optimization algorithms work better when there  is no need to switch between threads. Please also note that BindingList<T> is not thread-safe.
• Have only one message loop per application. Don’t create grids in different threads.Let us assume that the computer resources are not limitless. Theoretically the maximum performance can be obtained  if the number of threads equals to the number of processor cores. While a lot of threads are creating, they aren’t working in parallel.  In this case cores allocate time slices to threads based on their priority and consistently perform context switches (context switch is relatively expansive operation). Note, maximum time slice is about 10-15 msec.We have also take into account that each control paints its content in the GDI/GDI+ device (via the Graphics object).  While painting from one thread all others wait for GDI device to perform painting in its turn. Therefore if we start many  message loops – it doesn’t mean that we accelerate the application. In other words the application losses time on context  switches and on drawing in GDI device.

  From our point of view the application should have only one message pump. Windows has additional mechanisms  to optimize content drawing and we are not sure that they work in case of multithreaded environment. Of course,  business logic can work in any thread, but the graphical thread should be only one in the application.

• Use MethodInvoker to synchronize threads.In multi-threaded applications every call should be synchronized with the main thread containing windows message loop. Both Control.Invoke and Control.BeginInvokemethods may accept  different delegate types and their parameters. However, this causes a serious performance issue as they call  Delegate.DynamicInvoke(params object[] args), which in turn uses low-performance reflection. At the same time, for some delegates such as EventHandler, MethodInvoker and WaitCallback the code is called directly.  In the time of code execution the delegate is checked for belonging to one of the above types with specified number of parameters, and if it doesn’t – DynamicInvoke() is called.From practical point of view the synchronization process should look as follows:

  someControl.BeginInvoke(new MethodInvoker(delegate
  {
      //a code here
  }));

• Use objects of arbitrary classes instead of collections of values of string[] type, etc. It is more convenient and objects of arbitrary classes consume less memory than string collections.
• Don’t format values directly in data objects, i.e. if an object property is to return date, this field should return DateTime object type instead of string type. Use data formatting if needed. If properties return strings, they can be compared incorrectlyduring data sorting. Besides, comparing two strings requires more CPU resources than comparing two DateTime objects.

  class DateExample
  {
      ...
  
      //Bad idea
      public string FormattedDate
      {
          get { return string.Format("{0:yyyy-MM-dd}", _date); }
      }
  
      //Good idea: the property should return non-formatted value
      [Format("yyyy-MM-dd")]
      public DateTime Date
      {
          get { return _date; }
      }
  }

• Use the event-driven model, if possible. On global scale it is more efficient than searching for rows in one or more grids with dynamically changing data.
• Share the same business objects in different grids.  Use declarative binding. This simplifies the application code and significantly reduces memory consumption.
• Avoid using unnecessary wrappers. Use declarative binding instead of creating intermediate classes.
• Use statically declared EventArgs for data fields to avoid creating numerous short-lived objects when sending notifications via INotifyPropertyChanged interface.

  class MyDataObject : INotifyPropertyChanged
  {
      private static readonly PropertyChangedEventArgs Value1Args = new PropertyChangedEventArgs("Value1");
  
      private string _value1;
  
      public string Value1
      {
          get { return _value1; }
          set
          {
              if (_value1 != value)
              {
                  _value1 = value;
  
                  //Bad idea: short-lived object is created
                  FirePropertyChanged("Value1");
  
                  //Good idea: notify with an immutable static object
                  FirePropertyChanged(Value1Args);
              }
          }
      }
  
      private void FirePropertyChanged(string fieldName)
      {
          if (PropertyChanged != null)
          {
              PropertyChanged(this, new PropertyChangedEventArgs(fieldName));
          }
      }
  
      private void FirePropertyChanged(PropertyChangedEventArgs args)
      {
          if (PropertyChanged != null)
          {
              PropertyChanged(this, args);
          }
      }
  
      public event PropertyChangedEventHandler PropertyChanged;
  }

• Work with business logic objects directly instead of calling Cell.Value/Row.DataAccessor["fieldId"].ValueTypeDescriptor/PropertyDescriptor are used to display values in cells when working with arbitrary data types.
  The following code demonstrates value extraction from data objects.

  MyDataObject dataObject = ...;
  dataObject.Value1 = "some value";
  
  PropertyDescriptor property = TypeDescriptor.GetProperties(dataObject)["Value1"];
  object value = property.GetValue(dataObject);

  This working principle is the same for all grids of all vendors. The main issue is that PropertyDescriptor.GetValue() method uses reflection. NetGrid has an optimization that enables it to receive notifications from INotifyPropertyChanged/IBindingList without calling data object getters. Values are required only at the time of painting and only for visible cells. If the grid has a lot of rows, most of them are invisible and this approach significantly saves CPU resources. It is worth considering in application development. As an example, let’s review subscription to Grid.RowUpdated event:

  grid.RowUpdated += delegate(object sender, GridRowUpdateEventArgs e)
  {
      //This callback is called each time when a notification from INotifyPropertyChanged received.
  
      //Using of custom object will reduce CPU consumption
      MyDataObject myObject = (MyDataObject) e.Row.DataObject;
      decimal lastPrice = myObject.LastPrice;
  
      //The following call will use the reflection. Try to avoid.
      lastPrice = (decimal) e.DataField.Value;
  };

• Use new Row.IsInVisibleBounds property added to version 2.8.0.When updating data in real time in applications, the grid stores highlighting information for each updated cell. This default behavior causes serious consumption of memory resources in addition to CPU resource consumption  due to processing large volume of information. As most updates can occur outside the visible area, the programmer can save CPU resources by using the new property.

  //Disable authomatic highlighting (from INotifyPropertyChnaged interface)
  grid.Highlighting.Enabled = false;
  
  //This callback is called each time when a notification from INotifyProeprtyChanged received.
  grid.RowUpdated += delegate(object sender, GridRowUpdateEventArgs e)
  {
      //Handle updates only for visible rows
      if(e.Row.IsInVisibleBounds)
      {
          //Using of custom object will reduce CPU consumption
          MyDataObject myObject = (MyDataObject)e.Row.DataObject;
          double delta = myObject.LastPrice - myObject.PrevPrice;
          if(delta != 0)
          {
              Color color = delta > 0 ? Color.Green : Color.Red;
              //highlight the 'LastPrice' cell with specified semi-transparent color for 2 seconds
              e.Row["LastPrice"].Highlight(TimeSpan.FromSeconds(2), Color.FromArgb(50, color));
          }
      }
  };

  When this optimization is used, vertical scrolling may bring rows without cell highlighting information to the visible area and the user will not see cell highlights that were made before rows get to visible area of the grid. This concerns only highlighting information, while text and other cell content will display correctly. The programmer should decide whether to use such optimization or not.

• While construction of the hierarchy is preferable to collapse root rows:

  grid.RowAdded += delegate(object sender, GridRowEventArgs e)
  {
      e.Row.Expanded = false;
  };

• Turn off fading effect when building real-time applications:

  grid.Highlighting.Fading = false;

• Avoid settins colors, fonts in rows and cells because of high memory consumption (Colors and fonts are stored per cell or row). Use Grid.Appearance / Header.Appearence properties  and Grid.PaintRow / Grid.PaintCellevent handlers instead:

  //The back color is stored per cell. If grid has thousands rows, memory consumption can be very high.
  Cell cell = grid.Rows[0]["Price"];
  cell.Appearance.BackColor = Color.Red;
  
  //The back color is stored per row. If grid has thousands rows, memory consumption can be very high.
  Row row = grid.Rows[0];
  row.Appearance.BackColor = Color.Blue;
  
  //Good idea: colors are stored per grid
  grid.Appearance.EvenRows.BackColor = Color.FromArgb(10, Color.Red);
  grid.Appearance.OddRows.BackColor = Color.FromArgb(10, Color.Blue);
  
  //Good idea: colors are stored per header (therefore per hierarchical level)
  Header header = grid.Headers[0];
  header.Appearance.EvenRows.BackColor = Color.FromArgb(10, Color.Red);
  header.Appearance.OddRows.BackColor = Color.FromArgb(10, Color.Blue);
  
  //Good idea: colors are specified only at painting time
  grid.PaintRow += delegate(object sender, PaintRowEventArgs e)
  {
      e.Appearance.BackColor = e.Row.VisibleIndex % 2 == 0
                                   ? Color.FromArgb(10, Color.Red)
                                   : Color.FromArgb(10, Color.Blue);
  };

• Try avoiding reflection.
• Be very careful about creating temporary objects as it may result in memory pressure and make garbage  collector collect unused objects more frequently. Please note that when garbage is collected, all application threads  are temporarily stopped.
• Don’t use finalizers in objects unless necessary.

We hope that these simple recommendations will help you create efficient and high-performing applications.

We are happy to announce that a new grid version is out. The version 2.8.0 of .Net Grid has a lot of new performance improvements and new features.

Performance improvements

• Significantly improved BindingList performance, especially with objects implementing INotifyPropertyChanged interface. Here you may learn about causes of poor performance and methods for performance improvement.

• Significantly improved disposing performance for grids with a large number of sorted cells.

• Optimized real-time cell highlighting.

• Added new tutorials with practical guidelines on grid usage. The provided example shows impressive performance that can be achieved by following these simple guidelines.
• Significantly increased binding speed of sorted grid

New features

• RTL support (in the grid, editors, context menus, tooltips, reporting).
• Added support of merged columns for combining columns in groups with common header. Within these groups users may move columns, change column size and run sorting. Full customization of header appearance is supported including insertion of images, changing background color or fonts.
  
• Added Grid.Nodes.Insert() method enabling inserting data, not only at the end of the grid, but also in any position.
• Added Row.Insert() method enabling inserting data at any hierarchical level in any position.
• Foreground color blinking: Cell.Highlight(TimeSpan interval, Color backColor, Color foreColor) method was added.
• Public toolstrip items ToolStripGridColumn, ToolStripGridGroupBoxPanel, ToolStripGridHeaderConfigurator and ToolStripGridRemoveSort were added. Now a programmer can subscribe to Grid.HeaderContextMenu.ItemClicked event and get information of header and column where the click was made.
• Drag&drop support in grouped rows
• Added AllowNew, AllowRemove, AllowEdit setters in ThreadSafeBindingList<T>
• Possibility of using IFormat objects in unbound columns was added.
• Removing highlighting of entire row upon receiving notification from INotifyPropertyChanged with non-existent field.
• Support of themes in column filters
• Many other improvements (see full list here).

Dapfor’s developers continuously strive to improve .NetGrid performance and to add new grid features making it easier for developers to use and greatly increasing performance of grid-based applications. A convenient API makes cell highlighting and simultaneous data filtering, sorting and grouping with highest performance really trivial tasks. Any hierarchy can be created easily. Dapfor is the only grid vendor enabling use of thread-safe event driven model in the application.

We hope that you will appreciate grid quality, performance and convenience of interface. Let’s create feature-rich high-performance applications together.

Sincererly Yours,

Dapfor

It’s worth mentioning that handler of INotifyPropertyChanged notification is very poorly implemented. Low performance reflection is used for searching PropertyDescriptor and internal cache is very poorly organized thus significantly reducing performance. Specifically when the BindingList<T> receives notifications of new object, it compares this object with the previous object that was used for notification. If they are not identical, the binding list does a terrible thing – it runs through all objects to get the index of the notifying object. This seriously impacts performance when there are a lot of elements. When the number of elements is about 100 000, handling of a single notification takes about 1 ms, which is unacceptable for most applications.

In actual applications ListChangedType.ItemChanged event with ListChangedType.ItemChanged flag and set PropertyDescriptor is handled quite rarely. However, it is hard to disable INotifyPropertyChanged handling in a BindingList<T> via simple means. The only acceptable method of disabling handling is to use reflection. The thing is that the binding list in its constructor checks whether the data type implements INotifyPropertyChanged interface and sets raiseItemChangedEvents private variable to true if it does. Otherwise it is set to false. This variable influences only subscriptions to INotifyPropertyChanged interface. There is no direct access to this variable and it can be modified only via reflection. An example of code for this is provided below.

class CustomBindingList<T> : BindingList<T>
{
    public CustomBindingList()
    {
        FieldInfo fi = typeof (BindingList<T>).GetField("raiseItemChangedEvents",
                               BindingFlags.Instance | BindingFlags.NonPublic);
        if (fi != null)
        {
            fi.SetValue(this, false);
        }
    }
}

The above implements fully functional binding list with disabled handling of INotifуPropertyChanged interface events. At the same time the binding list notifies subscribers of adding or removing data just like in standard implementation of this container.

Some figures: In standard binding list implementation handling of 1000 notifications in 100 000 container took more than 600 msec. In optimized version this time – 0 since the container no longer subscribes to data objects. Besides that, no subscription enables memory saving.

This article concerns only binding list performance aspects. Another important aspect of working with binding lists INotifyPropertyChanged is their use in advanced binding.

Practically any well-designed application should support highlighting of data that changes in real time. However, practical implementation of this feature may be complicated and may significantly impact application performance, thus limiting its usability at high market volatility environment.

In classic implementation of cell highlighting concept the programmer has to store last update time for each grid cell. When cell value changes, the cell should be redrawn with a new color (e.g. when price changes – with green or red background depending on change type). After a certain time interval cell background color should be restored. However, this seemingly simple task is usually hard to implement. Firstly, this depends on data storage method and data volume. If there are too many rows and columns, memory consumption can be fairly high. Secondly, it is necessary to track highlighting time for each cell to restore colors. Some cells may be outside visible area, and this should be considered to save CPU resources. Besides, it is not possible to create high-performance applications without knowing working principles of the painting system and its optimal usages.

Grid grid = ...;
Cell cell = grid.Rows[10]["Bid"];
cell.Highlight(TimeSpan.FromSeconds(2), Color.Blue);

.Net Grid uses various optimizations that enable creation of efficient and high-performance applications. The programmer has only to use provided convenient interface and concentrate on application logic.

The performance of the .Net Grid using various benchmarks demonstrates excellent results. It was really hard work to achieve such high values for various performance indicators. Here are some of them:

• High insertion rate: 100 000 rows/second.
• High removal rate: 600 000 rows/second
• High grouping rate: 60 000 rows/second
• High real-time regrouping rate: 10 000 rows in a grid of 5 000 rows per second
• High real-time filtering rate: 7 000 rows in a grid of 5 000 rows per second
• Productive sort algorithms: 5 000 sorts in a grid of 5 000 rows per second
• Low memory consumption: The grid of 100 000 rows will consume 16 MB

Professionals working with complex systems will surely appreciate our efforts that make the code simpler and improve its reliability.

Both Control.Invoke and Control.BeginInvoke methods may accept different delegate types and their parameters. However, this causes a serious performance issue as the main code calling method is Delegate.DynamicInvoke(params object[] args), which in turn uses low-performance reflection. At the same time, for some delegates such as EventHandler, MethodInvoker and WaitCallback the code is called directly. In the time of code execution the delegate is checked for belonging to one of the above types with specified number of parameters, and if it doesn’t – DynamicInvoke() is called.

From practical point of view the synchronization process should look as follows:

    someControl.BeginInvoke(new MethodInvoker(delegate
    {
        //a code here
    }));

For comparison, if custom delegates are used, performance of Invoke call from non-GUI thread equals on the average:

Custom delegate: 25,000 calls per second.
MethodInvoker: 40,000 calls per second.

If Control.Invoke is called from GUI thread that doesn’t count inter-thread synchronization rate and doesn’t have context switches, the results are as follows:

Custom delegate: 150,000 calls per second
MethodInvoker:  1,200,000 calls per second.

The example code is provided below:

    ThreadPool.QueueUserWorkItem(delegate
    {
        int k = 0;

        DateTime dt = DateTime.UtcNow;
        for (int i = 0; i < 10000; ++i)
        {
            //CustomDelegate d = delegate { k++; };
            //Invoke(d, new object[]{EventArgs.Empty});

            Invoke(new MethodInvoker(delegate { k++; }));
        }
        TimeSpan ts = DateTime.UtcNow - dt;

        MessageBox.Show(string.Format("{0} invokes. Perf = {1} call/sec", k, 1000*k/ts.TotalMilliseconds));
    });

Summary. To improve performance it is always better to use MethodInvoker that improves performance by 50% when calling Control.Invoke method from non-GUI thread and tenfold when calling from GUI thread.