I found that UltraGrid is very slow to refresh after i make changes to the attached UltraDataSource. I followed Mike's article about UltraGrid's performance and added
this.ultraGrid1.BeginUpdate();this.ultraGrid1.SuspendRowSynchronization();
and corresponding Resume and EndUpdate functions but that didn't improve matters much. After some experimenting I got reasonable performance if I just set DataSource of my grid to NULL, do changes to data source and then assign my data source back to grid.
I just think I'm missing something here.
30 is quite a large number of bands in my opinion. In my experience, the sheer number of BindingManagers will cause serious performance problems in Visual Studio, regardless of what kind of data source you are using, when you reach about 8 bands.
Of course, there is no problem with UltraDataSource by itself, because when you just have the UltraDataSource and it's not bound to anything, no BindingManagers are created. The BindingManagers are created by the grid when you bind it.
Are you saying that there is some other data source in which you can add 30 bands while it's bound to the grid and it's not a problem? If so, what data source are you referring to?
Lev said:So would you suggest I do what I do right now - unbind ultragrid, do changes to datasrouce and bind it back? Or is there a better solution?
That seems like a reasonable way around the issue. It probably works better because the grid doesn't have to respond to each individual notification from every BindingManager every time you add a band - it only has to create everything once.
The sample I provided is very much representative of the issue - that was the whole point of creating the sample. Sounds like it's a problem inherent in the design of ultragrid. UltraDataSource by itself has no problems with large number of bands, and BTW 30 is NOT a large number of bands, ultragrid by itself has no problem with that number of bands - it's the combination that is not working well together.
So would you suggest I do what I do right now - unbind ultragrid, do changes to datasrouce and bind it back? Or is there a better solution?
Lev said:I was just trying to reduce my actual code to a small sample that reproduces the problem. In my real code I have an hierarchical structure with a lot of nested levels and a lot more rows so the problem is even more acute.
Well, the sample you have here is not really representative of the real issue, then, so it's not really much good to us in terms of figuring out what's going on here.
Are you doing something similar in your real application - and by that I mean, are you adding a large number of bands like your sample is doing? If so, then that might explain what's happening here. If you have a very large, complex, hierarchy of data with a lots of levels, then the BindingManager in DotNet is going to have serious performance issues. These issues would not occur when the data is not bound to the grid, because without the grid, the BindingManagers would not be created up front.
Actually disregard my last comment about no saving Visible Header Index - it works. Still would like to know how to solve the original problem without jumping through all these hoops.
I was just trying to reduce my actual code to a small sample that reproduces the problem. In my real code I have an hierarchical structure with a lot of nested levels and a lot more rows so the problem is even more acute.
I managed to get decent performance by detaching and then attaching back my datasource and Saving and loading back my DisplayLayout so that I still have column formatting, etc. One weird thing is that saving/loading back of DisplayLayout does not preserve Visible Header index - after DisplayLayout.Load my columns are in the wrong order.