Можно ли убыстрить загрузку в ListView ?

[AKit_3]

Можно ли убыстрить загрузку в ListView ? 60 000 записей загружается 1 минуту. Это очень медленно.

void method1()
{
    FormListItem mainItem ;
    int i ;

    LvElements.addColumn(0, new FormListColumn("First column", 0, 150));

    warning(Time2Str(timeNow(),1,1));
    For (i = 1; i <= 60000; i++ )
    {
        mainItem = new FormListItem("ing"); 
        LvElements.addItem(mainItem);
    }
    warning(Time2Str(timeNow(),1,1));
}

[Андре]

Пара общих советов, без привязки к Аксапте - из опыта WinApi.

1. Поищите пару методов, один из которых блокирует контрол от обнавления; другой разблокирует. Это позволяет избежать перерисовки контрола при добавлении новых элементов в цикле. Может быть это lock() и unlock() - честно говоря, пока нет времени проверить.

2. Попробуйте поиграться методом sort(). Дело может быть в том, что при добавлении каждого элемента listView может пересортировывать все значения, которые он отображает.

Еще раз - это только общие соображения и путь к поиску ответа. Может быть кто-то поможет более конкретным советом.

[mazzy]

Цитата:

Изначально опубликовано AKit_3
Можно ли убыстрить загрузку в ListView ? 60 000 записей загружается 1 минуту. Это очень медленно.

БАРДАК!

Мало того, эти 60000 записей загружаются на клиента.
Вместо того, чтобы обрабатываться на сервере.

Скажите - ЗАЧЕМ вы тянете эти записи на клиента?
Показать пользователю? 60 тыс. записей?

Что вы хотите добиться в конечном итоге?

[Андре]

Честно говоря, из кода не очевидно, что данные грузятся именно из БД.
Но в любом случае стоит подумать о том, что все данные пользователь просмотреть не сможет, а следовательно стоит ли грузить все ?
Можно подумать про virtual listview - в котором данные будут подгружаться по мере их отображения - но это уже много программирования. Если сама задача невелика, то не стоит и связываться.

[mazzy]

скорее это был тест сравнения с 1С.
Похоже, была попытка сравнить работу таблицы значений с... выбрали listView как наиболее подходящий по терминологии.

Другое дело, что listView используется в Аксапте так редко...
А таблица значений в 1С - так часто...


Уважаемые, думайте пожалуйста о быстродействии.
думайте в терминологии трехуровневости.
пытайтесь уменьшить количество передаваемых на клиента данных.
пытайтесь максимально загрузить СУБД и сервер приложений.
читайте Best Practice, наконец
http://technet.navision.com/usered/B..._Practices.htm

[AKit_3]

Не понял а куды мне их тягать - то ? Их юзер что тока через Grid увидать может ?

[AKit_3]

А читаю я с трудом. После второй страницы засыпаю.

[mazzy]

тогда зачем вам ускорять загрузку listView?

[Андре]

Я дома проверил свои предположения. Вот результаты:

Прежде всего, считаем, что данные отображаются не из датасета, а скажем вычисляются на лету, так как в противном случае выбор 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% выигрыш.

А вообще, если данных действительно так много - я бы посоветовал пересмотреть подход к отображению данных.
Например отображать их не все сразу, а какими-то логическими порциями.

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Андре
А вообще, если данных действительно так много - я бы посоветовал пересмотреть подход к отображению данных.
Например отображать их не все сразу, а какими-то логическими порциями.

В принципе, все уже есть для этого. Сделайте на форме DataSource, который будет привязан к нужной таблице. Данные из него берите с помощью getFirst(0, false)/getNext()...

[mazzy]

Цитата:

Изначально опубликовано Андре
Прежде всего, считаем, что данные отображаются не из датасета, а скажем вычисляются на лету, так как в противном случае выбор ListView на таком большом наборе данных мне кажется сомнительным решением.

И даже в этом случае выбор ListView мне кажется очень сомнительным.
Лучше уж временную таблицу...

Еще раз напомню - ListView полностью живет в свопе на клиентской машине.
Хоть застрелитесь, но он будет жить именно там.

[Андре]

Цитата:

Изначально опубликовано Maxim Gorbunov
В принципе, все уже есть для этого. Сделайте на форме DataSource, который будет привязан к нужной таблице. Данные из него берите с помощью getFirst(0, false)/getNext()...

Боюсь, что навигационный подход реализовать будет сложно. Дело в том, что довольно тяжело "поймать момент" когда следует вызывать getNext(). Надо привязываться либо к скроллингу listView, либо к свойству Selected() - оба способа очень не точны.
Я имел в виду случай, когда пользователь из интерфейса накладывает условия на возвращаемый набор данных, тем самым сужая возвращаемый набор данных.

[mazzy]

Цитата:

Изначально опубликовано Андре
Я имел в виду случай, когда пользователь из интерфейса накладывает условия на возвращаемый набор данных, тем самым сужая возвращаемый набор данных.

Тогда тем более не ListView.
На ListView придется самостоятельно еще и фильтрацию писать.

[Андре]

Цитата:

На ListView придется самостоятельно еще и фильтрацию писать.

Не надо фильтрацию писать
Надо просто очистить listView и загрузить новые item-ы.

А вообще, с ListView удобно работать в случаях, когда данные получаются не тупым копированием из БД.
Например следующая ситуация: мы считываем некие параметры из БД, на основании их в памяти вычисляем большой набор новых данных, которые хотим предоставить пользователю. В данном случае я не вижу смысла сохранять их в БД и отображать через Grid - гораздо проще отобразить их через ListView.
При этом возможны случаи, что таких данных может быть очень много и не стоит их все сразу отображать в listView.

[mazzy]

Мне кажется, что с ListView можно работать только в одном случае - если данных будет гарантировано мало. Во всех остальных случаях стоит подумать о таблицах.

Цитата:

Изначально опубликовано Андре
Например следующая ситуация: мы считываем некие параметры из БД, на основании их в памяти вычисляем большой набор новых данных, которые хотим предоставить пользователю.

А при фильтрации перевычислять?
А можно пример задачи, который стоит решать именно таким образом?

[Андре]

Цитата:

А можно пример задачи, который стоит решать именно таким образом?

ОК, например:

Допустим в процессе вычисления мы получили(а не считали из БД) map(Type::Container, Type::Real): [фамилия, имя, отчество] -> сумма.
При этом надо пользователб показать информацию Фамилия : Сумма.

Цитата:

А при фильтрации перевычислять?

Зачем перевычислять ? Все уже вычисленное хранится в Map. Надо просто очистить ListView и подгрузить туда нужную информацию.
Например на форме у нас есть ListView и ComboBox, содержащий первую букву фамилии. Перекрываем change() comboBox, в нем делаем listView.clear(); а затем пробегаясь по map-у выводим туда новую информацию.

p.s. Примеры и структуры данных придуманы только что и служат лишь для примерного описания возможности применения..

[mazzy]

понял...
но опять же нужен еще и map.
который в свою очередь опять в свопе на клиенте живет...

[Андре]

Цитата:

но опять же нужен еще и map.

Ну, это, в общем, довольно старый и стандартный подход к проектированию - есть данные(map) и есть их отображение/модель (listView). И связь между этими двумя сущностями должна быть минимальна.
Тогда без особых проблем можно будет заменить, как хранилище данных (например, map на container или врем. таблицу), так и их отображение (listView на Table или Grid).

Цитата:

который в свою очередь опять в свопе на клиенте живет...

Ну, во первых map-ы, очень и очень компактны, если не пихать в них все что попало, а только нужную информацию. Так например map { [фамилия, имя, отчество] -> сумма} при количестве элементов в десятки тысяч, будет занимать всего лишь около 10 Мб.
Во-вторых, по ним действительно очень быстро работает поиск. Посмотри, все длительные алгоритмы используют map-ы - сводное планирование, закрытие склада.

И потом, а какую альтернативу предлагаешь ты ? Засунуть все в БД ? Лишь для того, чтобы отобразить пользователю в Grid ? А как же траффик, а как же нагрузка не сервер ?

У этого метода есть один недостаток - плохая масштафируемость. Если ожидается, что количество данных, которые придется хранить в map'е возрастет на несколько порядков, то соответственно и возрастет требования к оперативной памяти на клиенте - этот момент следует учитывать.

[mega_guest]

Если вспомнить WinAPI, то ListView поддерживает так называем виртуальный список, вывод на экран при этом будет очень быстр (т.к. отображаются только те данные которые видны), но у клиента в памяти или на диске в файле все равно будет полный набор данных.

[Андре]

Я про это писал:

Цитата:

Можно подумать про virtual listview - в котором данные будут подгружаться по мере их отображения - но это уже много программирования.

Цитата:

Изначально опубликовано mega_guest: Если вспомнить WinAPI, то ListView поддерживает так называем виртуальный список, вывод на экран при этом будет очень быстр (т.к. отображаются только те данные которые видны), но у клиента в памяти или на диске в файле все равно будет полный набор данных.

Не, virtaul listView - это не когда отображаются данные, которые нужны. Этим занимается сама Windows. Перед перерисовкой рабочей области listView она вызывает InvalidateRect().
Virtual listView - это нечто другое. ListView владеет некоторой областью памяти, в которой хранит данные для отображения. И суть в том, чтобы заполнять эту память не сразу всеми данными, которые когда-либо могут отобразиться, а постепенно - по мере отображения нужных элементов, как правило в onPaint(). При этом мы избегаем загрузки элементов, котоорые могут быть не отображены.
Как ты правильно сказал, WinApi поддерживает listView, но это поддержку нужно реализовывать ручками

По идее, это даже не фича отдельного контрола, а один из элементов концепции "Data-Model", когда мы отделяем данные от их представления. Аналогичным образом реализуются Virtual TreeView, Virtual Grid и т.д.