Я дома проверил свои предположения. Вот результаты:
Прежде всего, считаем, что данные отображаются не из датасета, а скажем вычисляются на лету, так как в противном случае выбор ListView на таком большом наборе данных мне кажется сомнительным решением.
Итак, за основу берем первоначальный вариант:
PHP код:
void clicked()
{
FormlistItem formListItem;
int i, t;
;
lv.addColumn(1, new FormListColumn('Column', 1, 200));
t = WinAPI::getTickCount();
for (i=1; i<=30000; i++)
lv.addItem(new FormListItem('test' + int2str(i)));
info(int2str(WinAPI::getTickCount() - t));
}
При этом время выполнения: 11300.
Теперь блокируем listView от перерисовки на время вставки:
PHP код:
void clicked()
{
FormlistItem formListItem;
int i, t;
;
lv.addColumn(1, new FormListColumn('Column', 1, 200));
t = WinAPI::getTickCount();
lv.lockWindowUpdate(true);
for (i=1; i<=30000; i++)
lv.addItem(new FormListItem('test' + int2str(i)));
lv.lockWindowUpdate(false);
info(int2str(WinAPI::getTickCount() - t));
}
При этом время выполнения: 10100.
Прирост производительности, есть но не такой большой, как я ожидал.
Что еще можно порекомендовать:
1. Свойство viewType - поставьте report, если еще не стоит. Если вариант с list работает еще более менее, то icon и small icon работают на порядок медленнее.
2. Сортировка - свойство Sort. Хм... довольно неожиданный результат.
noSort - 10100
ascending - 7500
descending - 8100.
3. Можно поиграться из кода методом sort(). Он принимает целое число, и явно влияет на производительность. Но варианты передаваемого параметра нигде не задокументированны, а методом подбора мне удалось добиться только снижения производительности
Итого 7500, против первоначальных 11300 -> 33% выигрыш.
А вообще, если данных действительно так много - я бы посоветовал пересмотреть подход к отображению данных.
Например отображать их не все сразу, а какими-то логическими порциями.