Part 2
Being an LOB, composite applications infrastructure junky lately, I’ve been working around with several data-binding models and mechanisms to bind the data with the view, in a very efficient way of course. Sometime it was easy, and sometime it was not! I have had to find several workarounds to overcome both architectural and performance issues.
In this post I would like to concentrate on Data Virtualization, and to compare it with UI Virtualization, which are very similar, yet different aspects of the same problem.
After reading this post you'll have an idea of what is Data Virtualization compared to UI Virtualization, and what it is good for.
UI Virtualization
To understand what UI Virtualization is, lets say that you want to display a HUGE amount of data entries in a WPF DataGrid, all at once. In such case, trying to bind a simple WPF DataGrid with, lets say, 100,000 or more items, you’ll have to wait one or two seconds for the initial binding.
public partial class Window1 : Window
{
public Window1()
{
var hugeCollection = new HugeCollection();
DataContext = hugeCollection;
InitializeComponent();
}
}
<Window ...>
<Grid>
<tk:DataGrid ItemsSource="{Binding}" />
</Grid>
</Window>Well its really nothing!
Now lets change a little flag on the data grid.
<tk:DataGrid ItemsSource="{Binding}" VirtualizingStackPanel.IsVirtualizing="False" />Now, before you run this app, if you use a lap-top (like me… ;), connect it to an AC power adapter first. Trust me, your laptop will need that.
As you can see, the CPU stuck on 100% and it takes eternity to see the data (I just had to kill the process).
What’s wrong? It’s only a little flag: VirtualizingStackPanel.IsVirtualizing="False".
Well, it’s indeed a little flag that makes a big difference. If this flag is true (which is the default) it instructs the VirtualizingStackPanel (which is the default layout panel in a DataGrid, ListView, ListBox and other controls) to use UI virtualization. Means: don’t create data grid rows that are not visible to the user (in other words, are not in view). So this gives you a clue for what happened when we turned off this flag. We told VisrtualizingStackPanel not to use UI Virtualization, hence the DataGrid control tried to create and layout 100,000 rows! And this is a CPU killer as you saw.
Data Virtualization
WPF internally implements UI Virtualization and it’s great. In the previous case, UI Virtualization is just fine. We’ve got 100,000 items loaded in memory, and all we’ve had to do is to bound them with the DataGrid.
But what if each entry takes more than 1MB?
100,000 * 1MB = 97GB – Huston, we have a problem!
Well, the fast answer of course would be: Don’t load all items at once, instead use chunks. And this is exactly what Data Virtualization is!
Data Virtualization implementation raises several problems, and there is no out-of-the-box solution for Data Virtualization in WPF.
Well, first problem is: How do you fake scrollbars, so the user will think that it has all the data, and will be able to scroll?
Second problem: How do you filter, sort, group data that doesn’t exist?
Third problem: How do you search data (like this search) that doesn’t exist?
These are all tough questions.
So what do you think? Do you have an easy way or acceptable solution to solve this problem?
Next post I’ll introduce a unique solution, but till then I’ll be very glad to hear your opinion on that.