Производительность в выпадающем списке после изменения ItemsSource

Question

У меня есть сетка данных со столбцом комбинированных списков, определенным так:

<DataGridTemplateColumn x:Name="AssortmentQualitySettingsDataGridColumn" Header="Kvaliteter">
<DataGridTemplateColumn.CellTemplate>
    <DataTemplate>
        <ComboBox ItemsSource="{Binding Path=QualityInfoAssortmentCollection}">
            <ComboBox.ItemTemplate>
                <DataTemplate>
                    <StackPanel Orientation="Horizontal">
                        <CheckBox IsChecked="{Binding Path=ActiveQuality}"></CheckBox>
                        <TextBlock Text="{Binding Path=QualityName}" IsEnabled="False"></TextBlock>
                    </StackPanel>
                </DataTemplate>
            </ComboBox.ItemTemplate>
        </ComboBox>
    </DataTemplate>
</DataGridTemplateColumn.CellTemplate>

ItemsSource - это ObservableCollection объектов.Тексты для текстового поля в комбинированном ящике, тем не менее, редактируются в другой сетке данных и помещаются в другую коллекцию ObservableCollection с именем QualityItemCollection, и для получения обновленных комбинированных списков в сетке выше у меня есть событие в сетке данных, которое срабатывает при изменении этой коллекции.Это даже приводит к повторному чтению коллекции QualityInfoAssortmentCollection (необходимо также снова установить поле со списком, поэтому для его работы необходимо выполнить цикл).

Теперь, что происходит, когда в первый раз, когда данные загружаются, все хорошо и красиво, однако, когда обновление события QualityInfoAssortmentCollection сработало из вышеприведенных выпадающих списков, требуется 5-7 секунд, чтобы раскрыться при попытке получитьвнутрь.Само обновление я рассчитал, и на это уходит менее одной десятой секунды.У выпадающего списка не более 8-10 строк, и нет никакой разницы, пытаясь использовать виртуализированную панель стека, как это предлагается в другом месте.Сетка данных, отображающая ее, имеет около 10 строк, поэтому она даже близко не подходит к огромным объемам данных, которые необходимо перетасовать.

Редактировать: Дополнительные пояснения о невозможности использования определяющей коллекции QualityItemCollection.QualityItemColletion одинаково для всех элементов в приведенной выше сетке данных, но информация о том, какие флажки должны быть отмечены, установлена ​​для каждого элемента в приведенной выше таблице.Поэтому я делаю копию QualityItemCollection в QualityItemAssortmentCollection, в которой также есть bool для флажка.Возможно, есть лучший способ сделать это?

Редактировать 2: Попробовал профилировщик WPF сейчас, и он зависает так же, как программа, и ничего не показывает в то время, когда программа делает странные вещи.Однако оказывается, что это то, что делает Visual Studio, поскольку, если я запускаю программу самостоятельно, а не через Visual Studio, отсрочка не происходит.Yay.

Answer 1

Проблема была с отладчиком VS. Это по какой-то причине делает комбобокс мучительно медленным.

Answer 2

Итак, исправьте это?

, когда событие, обновляющее QualityInfoAssortmentCollection, запустило перечисленные выше выпадающие списки, занимает 5-7 секунд, чтобы раскрыться при попытке войти в него.* Где он проводит время?Не похоже, что вокруг нет профилировщиков.Вполне возможно, что это связано с WPF, и в этом случае эта ссылка:

http://msdn.microsoft.com/en-us/library/aa969767.aspx

также дает вам представление о профилировщике уровня WPF (т.е. вы можете увидеть, где WPF проводит время, что может быть ошибкой в ​​некоторых определениях WPF).

Также возможно отправлять слишком много несущественных событий обновления (всегда следует проверять, было ли изменено значение перед отправкой уведомления об обновлении).Таким образом, обновление может обновлять свойство до того же значения, вызывая другое обновление.Профилировщик позволит вам найти эти вхождения.

Никто здесь не сможет помочь вам - без кода и т. Д. Но профилировщик должен сделать совершенно очевидным, где тратится время.