Тормоза Silverlight DataGrid

Начал играться с Silverlight 3, обнаружил странность - при добавлении к строке шаблон детали, грид начинает сильно тормозит на большом количестве записей - без детали спокойно работает и с миллионом, а с деталью - жутко тормозит уже на 10 000.

 

Надо проверить, есть ли такая же фигня с гридом в Silverlight 2 Пример кода:

 

<data:DataGrid AutoGenerateColumns="True"

Name="msGrid" Grid.Row="1"

ColumnWidth="Auto"

RowDetailsVisibilityMode="VisibleWhenSelected"

RowDetailsVisibilityChanged="DataGrid_RowDetailsVisibilityChanged"

>

<!--uncommenting will cause severe perfomance degradation-->

<!--<data:DataGrid.RowDetailsTemplate>

<DataTemplate>

<StackPanel Orientation="Horizontal" Background="White">

<TextBlock Margin="5,5,5,5"

Width="350"

Text="Категорийный заказ на склад в Самаре!!!!"

TextWrapping="Wrap"></TextBlock>

</StackPanel>

</DataTemplate>

</data:DataGrid.RowDetailsTemplate>-->

</data:DataGrid>

Производительно Content Query Web Part

Недавно столкнулись вот с чем: Заказчик начал жаловаться, что страничка, на который аггрегируются новости из нескольких источников (хранящиеся в списках) загружаются очень долго. Для отображения и запроса элементов использовались несколько слегка модифицированный веб-частей "Запрос содержимого"(Content Query Web Part). Данные собирались с нескольких (около 10) списков, каждый их которых жил на своем узле. Время загрузке страницы иногда достигало 20 секунд, хотя время-от времени происходило мгновенно. Почему загрузка могла происходить очень быстро стало понятно - сразу работал кэш объектов, некоторое время хранящий результаты запроса. А вот поиск причины медленной работы занял два дня. Как оказалось, в результате некоторых организационных просчетов на production-сервере заказчика оказался список размером в 900 тыс, забитый практический бесполезной информацией. А все списки SharePoint хранитв одной таблице AllUserData, размер который разросся до 1 800 000 записей. Каждый запрос к ней, которых страничка делала по числу списков занимал около секунд, а 90% времени в каждом запросе - поиск по инждексу, даже несмотря на то, что то был Clustered Index Seek. Решение напрашивалось простое - удалить огромный список и все. Но и здесь возникли сложности - при попытке его удаления веб-приложение портала обрушивалось. Причина вноь оказалась на SQL сервере - при удалении, перемещение списка в корзну вызывалось попытку выполнить 900 тысяч INSERT в одной транзакции, чего бедный сервер, конечно не выдерживал. Только отключение корзины (кстати, это удобнее делать через stsadm) решило проблему