Улучшить скорость связывания - PullRequest
1 голос
/ 17 ноября 2011

При чтении документации кажется, что WPF использует отражение для привязки к объектам CLR. В моем приложении я связываю DataGrid с IList<T>, содержащим только 250 элементов (каждый с 8 свойствами). DataGrid использует виртуализацию, поэтому он выбирает свойства только для 30 элементов или около того. Все свойства являются простыми строками, и все же это занимает несколько сотен миллисекунд, что слишком много, если сравнить его с 40 мсек, которые потребовались для генерации этого списка с помощью сложного запроса к базе данных.

Есть ли какие-нибудь хитрости для улучшения времени привязки?

1 Ответ

1 голос
/ 17 ноября 2011

Итак, это предположение, но это случилось со мной раньше, и оно того стоит. Но прежде чем догадываться, профилировали ли вы свой код, чтобы увидеть точно , какие вызовы занимают больше всего времени? Я верю вам, когда вы говорите, что при использовании связывания время резко увеличивается, но предложение, которое я собираюсь дать, может быть доказано или опровергнуто с помощью профилирования результатов. Во всяком случае ...

Некоторое время назад я работал над приложением, которое генерировало множество небольших элементов пользовательского интерфейса. Каждый элемент был экземпляром UserControl и использовал привязку данных для своего появления. Я заметил, что при генерации многих (200+) из этих элементов было заметное отставание.

Мы использовали Prism и его класс ViewModelBase, передавая делегаты методу RaisePropertyChanged, т.е.

private int _foo;
public int Foo
{
    get { return _foo; }
    set
    {
        if( _foo != value )
        {
            _foo = value;
            RaisePropertyChanged( this.Foo );  // trouble
        }
    }
}

Проблема в том, что реализация RaisePropertyChanged должна использовать отражение, чтобы получить имя свойства в виде строки. Когда многие (и я имею в виду много) из них были уволены, был значительный удар производительности.

Решение? Используйте строку вместо объекта функции. Да, это действительно все, что нужно. Это немного воняет, потому что вы должны помнить, что нужно изменить две вещи, если вы когда-либо проведете рефакторинг этого свойства, но, честно говоря, снижение производительности не стоит этого во многих обстоятельствах.

В любом случае, попробуйте. Если внутри RaisePropertyChanged тратится много процессорного времени, вполне вероятно, что это так.

...