I have a Grid that has a large number of columns, one for each day. There could be 100s of columns in this DataTable for those many days. After the DataTable is bound to the Grid, I am setting the width of each column as you see in the code snapshot.
I find it hard to understand why setting the Width is so expensive. It takes 24.86 compared to setting the Format on the next line which take only 0.003 . I found it hard to believe at first but repeated runs of C# profiler confirmed this inefficiency.
Is there a way I can avoid setting the column width one at a time. Is there Grid level or row level setting? Or some other suggestion?
Thanks!
I am on version 7.3
Hi Campbell,
I remember fixing an issue like this a while back. I recommend getting the latest service release.
We are also experiencing severe performance issues when setting column width, which seems to get exponentially worse the more columns there are.
For testing purposes I have removed any event handlers on the grid, so all I'm doing is looping through each grid column and assigning grid.DisplayLayout.Bands(i).Columns(j).Width. To be sure I am doing everything I can, I've called SuspendLayout, SuspendRowSynchronization and BeginUpdate on the grid before iterating the columns.My findings with 2 bands, (1 row in first band, 10 rows in 1st row child band) are as follows:
With 20 columns, it took 0.006 seconds to set the widths, i.e. 0.3ms per columnWith 50 columns, it took 0.046 seconds to set the widths, i.e. 0.92ms per column.With 728 columns, it took 34.3 seconds to set the widths, i.e. 47ms per column.With 2916 columns, it took 1,131.0 seconds (nearly 19 minutes!!!) to set the widths, i.e. 388ms per column.This is using version 9.2.20092.2049Could you please let me know if any progress has been made on this, or whether you need me to raise a formal bug report.Thanks,Campbell
Hello vrn,
Did Mike's answer resolve the issue? If so, please verify it as the answer.
vrn said:If I move code to InitializeLayout, would it help to have the BeginUpdate/EndUpdate in InitializeLayout?
It depends what you are doing, but yes I would use BeginUpdate/EndUpdate. It can't hurt and it might help. :)
vrn said:How about Resume/SuspendRowSynchronization()? Makes senses if I use it in InitializeLayout? or only in other methods?
These are typically useful when you are modifying the data source that the grid is bound to. I don't think there is any benefit in using these if you are modifying the grid directly, such as the column width. But again, it could not hurt.
Infragistics Mike Saltzman said: Also, if you are looping through the grid columns and setting lots of properties on a lot of different columns, it's a good idea to try to make this code as efficient as possible. I recommend that you do this in the InitializeLayout event of the grid, if you can.
Also, if you are looping through the grid columns and setting lots of properties on a lot of different columns, it's a good idea to try to make this code as efficient as possible. I recommend that you do this in the InitializeLayout event of the grid, if you can.
If I move code to InitializeLayout, would it help to have the BeginUpdate/EndUpdate in InitializeLayout?
Infragistics Mike Saltzman said: Also, you should use the BeginUpdate/EndUpdate methods on the grid. There is further discussion of this technique in the WinGrid Performance Guide.
Also, you should use the BeginUpdate/EndUpdate methods on the grid. There is further discussion of this technique in the WinGrid Performance Guide.
How about Resume/SuspendRowSynchronization()? Makes senses if I use it in InitializeLayout? or only in other methods?