DataboundGrid with comboboxes scrolling sluggish

[Administrator]

Hi,

We are using Databound grid (Syncfusion 1.6.1.5) which has some comboboxes. If we have lot of data (say few hunder records) in the comboboxes, it is very slow.

Please run the attached sample. The top databoundgrid has comboboxes. The bottom one has textboxes. Both of them have same amount of data. When you scroll the top grid, it is very slow when you have lot of data.

1. Run the sample.
2. Click Setdata button. See the times. Top one takes 2.09 secs to set the data. Bottom one takes around 0.09 secs.
3. Also notice the difference in painting when you overlay another window on top of just the first grid and then only on second grid. Second grid paints much faster.

Can you let me know why the gird is so slow?

thanks,
- Reddy

[Administrator]

Reddy,

I am trying your sample, but if I just use your default 200 setting, the differences I see from the times on the top and bottom are a factor of 2, but not the 20 you see. The top value ends with .25xxxx and the bottom ends with .12xxxx. Am I reading these numbers wrong?

How are you testing the scrolling? Are you moving the thumb quickly or mousing down on the scroll buttons?

I will continue to look at it, but wanted to make sure I understand the problem.

The basic difference is that the combobox has to make a value look up to get the displaymember. This value lookup is a linear search of the list. And the textBox does not have to do this.

One other point is that you are forcing the combobox cell to change datasources since you have two different lists. With small lists, this is not normally a problem, but with large lists it can be. One simple work around is to add additional combobox CellTypes with (grid.Model.CellModels.Add). If you have a special combobox for each list, then they will not have to be swapped.

[Administrator]

Clay,

I ran my sample again in VS.NET 2003 in debug mode. I took some screenshots for you (se attachment). The top one takes around 2.5 secs and bottom one takes 0.12 secs.

To scroll, I am dragging thumb up/down. I noticed that most of our users do scrolling like this. If the thumb is too small to hold, they will use scroll buttons.

We have lots of comboboxes throughout the application. It will be very time consuming to comeup with a saperate combobox for each list. We have as many as 4, 5, 6 comboboxes sometimes in a grid. With more and more data, grid is getting slower.

Can this combobox cell somehow cache in the display value to avoid the costly linear search. Also, until the user clicks in a cell, we don't have to put any editor in the cell. So can this combobox cell be intelligent enough to avoid switching between the datasources.

thanks,
- Reddy

[Administrator]

The comment about the linear lookup is not entirely correct.

If your list is an IBindingList, and IBindingList.SupportsSearching is true, then the grid will use the list's Find method which may not be a linear search depending upon the implementation.

[Administrator]

This is a very serious issue. I have same the situation with a grid with 10 drop down columns and it gets very slow.

Following Clay advice, I created additional combobox CellTypes for each column but it didn't make any different in performance at all.

Also tried to work around a custom ComboCellModel overriding FillWithChoices and GetFormattedText methods but nothing we can improve from outside.

Any further comments on this issue will be appreciated.

Thanks

[Administrator]

Reddy,

I suspect the difference is with 1.0 vs 1.1. With 1.0, attached is the picture I get. It has times like .25 vs .13. But with 1.1, I see times like 5.0 vs .13. It looks like something slowed down significantly between the versions. We have no version specific code in the grid so we will have to investigate what is happening here.

Jose,

Are you using 2003 as well? What are the datasources that you are using for the comboboxes?

[Administrator]

I'm using VS 2003 and my datasources are IBindingList.

[Administrator]

I looked a bit into this.

It seems the main issue is that with 1.1 at the time you set the DataSource for a ListBox the listbox will loop through all items in the datasource. I don't think that did happen with 1.0.

I added a new property CacheDataSource to GridComboBoxCellModel. That change will go into the next patch and should be available later this week.

You can then initialize the cell model as follows:

private void FormatGrid1()
{
// cache grid model and binder
GridModel gridModel = this.gridDataBoundGrid1.Model;
GridModelDataBinder gridBinder = this.gridDataBoundGrid1.Binder;

GridComboBoxCellModel cm = (GridComboBoxCellModel) gridModel.CellModels["ComboBox"];
cm.CacheDataSource = true;

If you set this property to true then the combobox will maintain several ListBoxes in a hashtable. That way the grid won’t have to swap the DataSource over and over again.

However, there is another issue with ArrayList. It implements ICloneable. Therefore, whenever a style is passed to the cell renderer the array gets cloned. That’s how all properties in GridStyleInfo work. If an object implements Icloneable then it will be cloned before it gets assigned to a cell.

Therefore ArrayList itsself is not a good solution. Better is a strongly typed list that does not implement ICloneable. With that list you could also add support for binary searching by implementing IBindingList.SupportsSearching. I modified your sample code to give you an example how to implement such a list. Once a newer patch is available you can give that sample a try. You should not notice any difference anymore between the two grids.

The solution with CacheDataSource is only a temporary fix. In the 2.0 version I’ll make sure we get rid of the dependency on ListBox to do a key lookup. That should then permanently solve that problem with quickly swapping out the data source.

The modified sample is attached.

Stefan