바인딩 속도 향상

Question

설명서를 읽을 때 WPF에서 리플렉션을 사용하여 CLR 개체에 바인딩하는 것처럼 보입니다. 내 응용 프로그램에서는 DataGrid을 IList<T>에 바인딩합니다. 항목 수는 250 개 (각 속성은 8 개)입니다. DataGrid은 가상화를 사용하므로 30 개 항목 정도의 속성 만 가져옵니다. 속성은 모두 단순한 문자열이며 여전히 복잡한 데이터베이스 쿼리를 통해 해당 목록을 생성하는 데 소요 된 40 밀리 초와 비교하면 너무 오래 걸리는 수백 밀리 초가 걸립니다.

바인딩 시간을 개선하기위한 트릭이 있습니까?

Answer 1

이것은 추측이지만 이전에 나에게 일어난 일이며 가치가 있습니다. 짐작하기에 앞서, 코드를 프로파일 링하여 정확히 전화가 걸리는 시간을 확인하십시오. 바인딩을 사용할 때 시간이 급격히 늘어났다 고 말할 때 나는 당신을 믿습니다. 그러나 제가 제시하려고하는 제안은 프로파일 링 결과로 입증되거나 불일치 될 수 있습니다. 어쨌든 ...

저는 얼마 전에 작은 UI 요소를 많이 생성하는 응용 프로그램을 만들었습니다. 각 요소는 UserControl의 인스턴스이고 데이터 바인딩을 사용하여 모양을 나타냅니다. 나는 많은 요소 (200 개 이상)를 생성 할 때 상당한 요소가 있다는 것을 알아 차렸다.

우리는 즉, RaisePropertyChanged 방법 대표단에 전달 프리즘과 그 ViewModelBase 클래스를 사용하고,

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

이 문제는 RaisePropertyChanged의 구현이 같은 속성 이름을 얻기 위해 반사를 사용해야한다는 것입니다 끈. 이 중 상당수 (그리고 나는 많은 것을 의미)가 해고 당했을 때 중요한 성과가 나타났습니다.

해결책? 함수 객체 대신 문자열을 사용하십시오. 네, 그게 전부입니다. 그것은 당신이 속성을 리팩토링한다면 두 가지를 바꾸어야한다는 것을 기억해야하기 때문에 약간 악취가납니다. 그러나 솔직히 말해서 성능 저하는 많은 환경에서 가치가 없습니다.

어쨌든, 한번 해보십시오. 많은 CPU 시간이 RaisePropertyChanged 안에있는 경우 그 이유가있을 수 있습니다.