Производительность WPF Datagrid - PullRequest
Новая
       13

Производительность WPF Datagrid

2 голосов
/ 23 сентября 2010

У меня очень большой текстовый файл с разделителями-запятыми. Мне нужно отобразить это в таблице данных WPF, какой метод приведет к максимальной производительности загрузки всех данных в сетку? Мне известны только два метода:

  • Использование Datatable и добавление каждой строки в виде строки (выглядит как перебор)
  • Используя ObservableCollection, создает объект для каждой строки (выглядит как перебор)

Существует ли третий способ заполнения Datagrid, который дал бы более высокую производительность?

Ответы [ 2 ]

2 голосов
/ 24 сентября 2010

Зависит от того, что вы собираетесь делать с данными.Если данные будут доступны только для чтения, вы можете определить List и установить его в качестве ItemsSource для сетки данных.Затем сетка данных автоматически создаст все строки для представления элементов в списке.

Если вы хотите манипулировать данными, вы можете использовать BindingList <> или ObservableCollection <>.

Как это"создает объект для каждой строки" излишним?Вы должны представить строку / строку данных как объект.Это просто здравый смысл, иначе это сделать невозможно.

По сути, если производительность - это то, что вам нужно, то ItemSource таблицы данных должен быть как можно более легким.DataTable может быть излишним, если вы не собираетесь использовать все его функции.Список <>, с другой стороны, настолько легок, насколько это возможно.

Также обратите внимание, что сетка данных WPF по умолчанию использует виртуализацию, что также способствует повышению производительности.Существуют некоторые предостережения, например, не помещайте сетку данных в стековую панель, иначе эффект виртуализации исчезнет - вы можете узнать об этом в Google.

И последнее, по моему опыту, встроенная сетка данных .NET4 WPF имеетсерьезная ошибка дизайна.В основном каждый DataGridRow потребляет 1 МБ памяти даже для самых простых данных.С виртуализацией и отображением только 30 строк, это не слишком большая проблема - потребляется всего 30 МБ памяти.Но возьмите тысячу строк, отключите виртуализацию и потребление памяти составит 3 ГБ !!!!Напротив, сетевое представление данных WinForm потребляет в 10 раз меньше памяти с теми же данными.Даже если виртуализация отключена, тысяча строк занимает всего 30 МБ ...

Я обнаружил ошибку в Connect, но специализированные эксперты еще не изучили эту проблему.Не уверен, что сетка данных инструментария WPF ведет себя лучше ...

0 голосов
/ 24 сентября 2010

Вы можете привязать к DataView, если загружаете файл с разделителями-запятыми, используя OleDb.
Примечание: я не тестировал большой набор данных.

Вот привязка к DataGrid: 

<Window x:Class="DatagridBackgroundWorker.Views.MainView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:WpfToolkit="clr-namespace:Microsoft.Windows.Controls;assembly=WPFToolkit" 
    Loaded="Window_Loaded"
    Title="Main Window" Height="400" Width="800">
  <DockPanel>
    <Grid>
        <WpfToolkit:DataGrid  
            ItemsSource="{Binding Path=GridData, Mode=OneWay}" >
        </WpfToolkit:DataGrid>
    </Grid>
  </DockPanel>
</Window>

Вот ViewModel: 

public class MainViewModel : ViewModelBase
{
  public MainViewModel()
  {
     // name of the file
     string fileName = "MyData.txt";

     // location of the file
     string filePath = Environment.CurrentDirectory;
     string connection = @"Provider=Microsoft.Jet.OleDb.4.0; Data Source = " +
                         filePath +
                         ";Extended Properties=\"Text;HDR=Yes;FMT=Delimited\"";

     OleDbConnection conn = new OleDbConnection(connection);
     conn.Open();
     OleDbDataAdapter adapter = new OleDbDataAdapter("SELECT * FROM [" + fileName + "]", conn);
     adapter.Fill(_ds);
  }

  private DataSet _ds = new DataSet("MyDataSet");
  public DataView GridData
  {
     get
     {
        return _ds.Tables[0].DefaultView;
     }
  }
}

Вот файл данных, который я использовал: 

name,site,extra
jeff,codinghorror,stackoverflow
joel,joelonsoftware,stackoverflow
zamboni,secondbeach,stackoverflow
...