User (Old forums)MemberJune 18, 2007 at 8:58 pmPost count: 23064
The grid is very slow to load and scroll large amounts of data. For my test I am using a DataTable with 5000 rows and 50 columns, each element is of type string. I create a new DataGridControl, added it to the Window and set its ItemsSource property to the DefaultView of the DataTable. Wrapping the DataView with a DataGridCollectionView yields the same result. Am I doing something wrong? A WinForms DataGridView loads and scrolls the exact same data much faster. I noticed the online demo that binds to a datagrid stutters a bit while holding down the scroll button, its more noticeable on my slower machines.
We are looking to redo some of our existing screens in WPF, should we stick with a WinForms grid for the screens that need to display large amounts of data? Do you see the performace getting to a usable state(at least comparable with a winforms grid) over the next 6 months or so?
Any information would be helpful.
Imported from legacy forums. Posted by Bill (had 9207 views)Xceed SupportMemberJune 19, 2007 at 8:35 amPost count: 5658
Due to the nature of the Windows Presentation Framework, there are currently some performance issues when compared to WinForms when displaying large amount of elements.
Effectively, when considering the Layout system, the Animation system, the Templating system, the DependencyProperty inheritance system, the DataBinding system, the RoutedEvent system; there is a huge amount of things going on in the background, and unfortunately that takes its toll on the general application performance.
Usage of the DataGridCollectionView should improve the performance of Sorting/Grouping as well as improve modifying a Sorted/Grouped data set. General loading time should not really by affected by the DataGridCollectionView.
Concerning your more particular needs, can you provide us with your basic time estimates for the loading / scrolling of the DataGridControl as well as the number of items visible in the grid. This could help us detect if something could be problematic with your setup.
Imported from legacy forums. Posted by Marcus [Xceed] (had 266 views)User (Old forums)MemberJune 19, 2007 at 9:47 amPost count: 23064
Thanks for the reply. I will put together a quick sample and send it off to support. We would like to be able to show the grid full screen and have it scroll without a delay. I’m not really interested in sorting/grouping (yet!), i’d like to be able to scroll a grid of data first. I don’t have any particalur estimates for loading/scrolling except that i’d like users to not have to ask, “what is the grid doing?” when they drag the scroll thumb and drop it at the bottom of the grid and have to wait 2-3 seconds for the grid to paint.
I understand the overhead of WPF, I’ve been able to see it first hand using profilers to try and determine what is going on when scrolling. I realize this is not an Xceed grid issue, as the infragistics grid is unusable as well, do you know if there will be any performance gains with WPF in .NET 3.5?
Imported from legacy forums. Posted by Bill (had 947 views)User (Old forums)MemberJune 19, 2007 at 2:35 pmPost count: 23064
As a follow up, i noticed the more columns in the datatable, the slower the grid responds, even if the columns are not visible. It also seems to bloat memory. I created a datatable with 5000 rows and 250 columns. The datatable itself takes up about 80 meg of memory. When binding to the grid memory consumtion balloons to 340 meg, and also takes a long time to draw. In comparison when binding to a the WinForms datagridview memory only goes up by 3 meg. Will this be addressed in a future release?
I emailed a sample app to support.
Imported from legacy forums. Posted by Bill (had 1016 views)Xceed SupportMemberJune 19, 2007 at 2:49 pmPost count: 5658
The fact that the number of columns affects performance is just as indicated previously… The more visual elements are created, the greater the hit on the performance…
Imported from legacy forums. Posted by Marcus [Xceed] (had 668 views)User (Old forums)MemberJune 19, 2007 at 3:21 pmPost count: 23064
But does this grid use any virtualization techniques? Something like described here:
Imported from legacy forums. Posted by Sergey (had 1024 views)User (Old forums)MemberJune 19, 2007 at 3:24 pmPost count: 23064
If the columns are not on screen why are visual elements being created for them? I don’t see this behavior with the WPF ListView control (in gridview mode) , it displays quickly no matter how many columns are in the underlying datatable(althought paging down is pretty brutal as well) . It would be nice if the grid scrolled up and down as quickly as it does left to right.
Is anyone else concerned about these issues? Whats the point of grouping and sorting data if my dataset has to be so limited in size?
In the documentation there is a note on the property CellEditorDisplayConditions that says this:
Including Always when setting the CellEditorDisplayConditions property will have a significant negative impact on performance.
Should the documentation be updated to have a word on performace with regard to the amount of columns in your data?
Imported from legacy forums. Posted by Bill (had 750 views)User (Old forums)MemberJune 19, 2007 at 3:51 pmPost count: 23064
Performance is everything, who needs bells and whistles if it takes 10 seconds to load. It’s like driving a car, you can forgive lack of air conditioner if it’s a Formula 1. In our application (shrink-wrap product you can buy in stores) many users have lists of data reaching 100 000 records (about 30 columns).
My hope was to use Xceed grid to make WPF switch a bit easier, but performance is a #1 priority.
Imported from legacy forums. Posted by Sergey (had 882 views)User (Old forums)MemberJune 19, 2007 at 7:40 pmPost count: 23064
Well after reading the help, virtualization is supported.
Supports UI virtualization, even when grouping data, so only elements currently in view are created and kept. Provides faster loading time, uses less memory
Imported from legacy forums. Posted by Sergey (had 1179 views)User (Old forums)MemberJune 19, 2007 at 7:50 pmPost count: 23064
it seems like the rows are being virtualized but the columns are not. The more columns I add to the underlying data source increases the memory footprint and the load time, regardless if the columns are displayed or not.
Imported from legacy forums. Posted by Bill (had 656 views)Odi [Xceed]SpectatorJune 20, 2007 at 1:26 amPost count: 426
Responding to various comments in this thread:
>>I don’t have any particalur estimates for loading/scrolling except that i’d like users to not have to ask, “what is the grid doing?” when they drag the scroll thumb and drop it at the bottom of the grid and have to wait 2-3 seconds for the grid to paint.
Nice way of putting it. We agree. Between v1.0 and v1.1, our development team spent most of those months working exclusively on performance, and they achieved noticeable improvement. In many situations, we have reduced grouping and sorting times to 1 to 2 seconds, going up to 3 seconds when reaching 100000 rows. Scrolling speed was also improved to the point where real-time scrolling could be enabled, even if still somewhat sluggish at times. We considered these speeds a whole lot more usable than taking minutes or hours like the competition (last we were informed). We also mentionned when v1.1 was released that we understood this still wasn’t perfect, and would continue working on the performance.
>>I realize this is not an Xceed grid issue, as the infragistics grid is unusable as well, do you know if there will be any performance gains with WPF in .NET 3.5?
We don’t know for sure, but we are being proactive and are working directly with Microsoft’s WPF team on two fronts: making sure their developers and PMs obtain the information they need to know what parts of WPF they have to improve, and obtaining their help for improving Xceed DataGrid for WPF for it’s upcoming versions. This is happening right now actually.
>>It seems like the rows are being virtualized but the columns are not.
This is under consideration. It might ensure that the speed isn’t further degraded by having many columns, but there are a few drawbacks. It may have to wait until the core issues (speed is improved when there aren’t many columns) have been sufficiently addressed.
>>Is anyone else concerned about these issues? What’s the point of grouping and sorting data if my dataset has to be so limited in size?
Your comment only applies if indeed you have a large dataset, and not everybody does, so the grouping and sorting features have their uses. However, we are aiming to please developers that are working with large datasets too. At this early stage in the WPF game, grouping and sorting that takes a second or two with tens of thousands of rows, or 3 seconds with 100000 rows is as good as it gets. We are still working on it, it will only get better.
>>Performance is everything, who needs bells and whistles if it takes 10 seconds to load. It’s like driving a car, you can forgive lack of air conditioner if it’s a Formula 1.
Some developers need those air conditioners too… A lot of work was put into performance so far, and continues to be, but we have to throttle (pun intented) the energy we put into this, because we’re not entirely sure there’s a whole lot more we can do. Certain things may indeed be beyond our control and will have to be improved in the next WPF iteration. Keep in mind that the more you and others chime in and make this an issue, the higher the priority of performance becomes. We hear you.
Imported from legacy forums. Posted by Odi [Xceed] (had 941 views)User (Old forums)MemberJune 20, 2007 at 8:29 amPost count: 23064
Id like to adress performance issues as well. There has been large progress since v1.0. But as someone metnioned here, we need data grid which performance is comparable with WinForms products. Lets hope WPF team will take performance issues seriously, so we can completely abadon WinForms in our applications.
Imported from legacy forums. Posted by Peter (had 823 views)User (Old forums)MemberJune 20, 2007 at 10:24 amPost count: 23064
I am using dot net 3.5 beta
and binding to a derived ObservableCollection<DependencyObject> implementing IBindingList and do see some performance improvements over .NET 3.0 and binding to DataTable or DataView
Imported from legacy forums. Posted by MiddleTommy (had 793 views)User (Old forums)MemberJune 20, 2007 at 11:49 amPost count: 23064
thanks for your responses they are very helpful.
I’d like to report that i have tried the latest version of the infragistics grid and i’d have to say that it is no longer “unusable” with respect to large datasets, it still has its own set of issues… like whats up with no column reordering support…
anyhow, we’ll switch over to that for the time being for our demos, this is fun…I can’t wait to see what the other 3rd party vendors pump out over the next few months…
Imported from legacy forums. Posted by Bill (had 9079 views)User (Old forums)MemberSeptember 23, 2010 at 4:28 pmPost count: 23064
I am trying to move to the exceed wpf grid from an infragistics winforms grid. Just came across this thread. Is there any update on this. Is the performance better that the winforms grid now?
Imported from legacy forums. Posted by Shailesh (had 685 views)
- You must be logged in to reply to this topic.