[Элементы GUI] Много данных, виртуальный ListView и сортировка

[veretragna]

Здравствуйте, товарищи!
Есть следующая проблема.

Я написал скрипт, который собирает данные со страницы, анализирует их и сохраняет в собственном текстовом формате. Сохраненных страниц очень много, вполне можно насчитать до тысячи, для каждой страницы создается отдельный файл, в каждом хранится примерно 400-500 знаков значащего текста.
Кроме того, во время старта программы изо всех сохраненных страниц надо считать эти 400-500 знаков и отобразить свойства сохраненной страницы типа даты, времени, идентификатора и набора разнообразных чисел, которые надо отобразить в элементе ListView. В среднем на загрузку 10 страниц уходит около 0,3 секунд, но 100 страниц - это уже 3 секунды, а 1000 - 30 секунд, а при запуске программы это очень много.
Для оптимизации быстродействия работы программы я решил попробовать использовать виртуальный ListView (стиль $LVS_OWNERDATA), но пока не реализовал это. Судя по тому, что я знаю об этом режиме, вместо 1000 элементов за раз подгружается максимум 30 файлов (столько, сколько влезает на экран), и должно быть молниеносно быстро. Но тут возникает другая проблема - с сортировкой. Если мне нужно отсортировать страницы по одной цифре-показателю, это подразумевает, что надо абсолютно все страницы выгрузить в оперативную память (пусть даже по очереди), там сортировать, и уже тогда отобразить в ListView. В итоге получается точно та же проблема - на сортировку данных в памяти тратится ровно столько же времени, сколько и на стартовую загрузку страниц в обычный, не-виртуальный ListView, или даже больше.

Вот на этом моменте нужна Ваша помощь, товарищи. Можно ли сортировку оптимизировать? Обязательно ли грузить все страницы для сортировки? Я даже смотрел в сторону централизованного хранения страниц в базе данных для моментального получения всей базы цифр, но это не совсем удобно, и надо переделывать всю подсистему хранения под корень.

Как быть?

 

[veretragna]

Что, правда ни одного варианта?

 

[Prog]

Не видя кода сложно что-то посоветовать, ведь мы не знаем как все делано, а значит не можем однозначно ответить что именно нужно оптимизировать.
Но могу предположить что снижение скорости работы связано с низкой скоростью интерпретации скрипта. Как реализована сортировка?
Возможно ускорить получится лишь переписав код на другой ЯП, компилируемый и быстродействующий.

 

[Yashied]

Попробуйте продумать алгоритм сортировки в "фоновом" режиме. Я имею виду не отдельный поток, а сортировку в тот момент, когда скрипт "бездействует". Естественно, в этом случае нужно предусмотреть возможность поставить сортировку на паузу, а затем возобновить ее. Второй вариант, это запихнуть алгоритм сортировки в .dll или машинный код, можно даже в отдельный поток. Но в этом случае придется как минимум хранить все данные LV в структурах.

 

[veretragna]

Попробуйте продумать алгоритм сортировки в "фоновом" режиме. Я имею виду не отдельный поток, а сортировку в тот момент, когда скрипт "бездействует". Естественно, в этом случае нужно предусмотреть возможность поставить сортировку на паузу, а затем возобновить ее. Второй вариант, это запихнуть алгоритм сортировки в .dll или машинный код, можно даже в отдельный поток. Но в этом случае придется как минимум хранить все данные LV в структурах.

Сортировка в фоновом режиме вряд ли поможет (она ведь должна выполняться по запросу-щелчке на колонке ListView, а колонок там 12 штук и по всем нужна отдельная сортировка - для дат одна, для идентификаторов уже другая, для численных переменных нужно преобразование в Int и т.д.), а сортировку на машинном коде с последующей передачей в AutoIt, думаю, сделать вполне реально
Хранить данные в DllStruct - не проблема, алгоритм организован так, что его под эти цели можно легко преобразовать.
Задача интересная и сложная, буду работать над этим, о результатах напишу отдельно. Или, если окажется, что задача неразрешима за приемлемое время на AutoIt, полностью перенесу на С++ и всего делов.

 

[veretragna]

Решил проблему радикально, обошелся и без виртуального ListView, и без сортировки в машинном коде.
Сделал следующим образом:
1) заголовок файла со значащими данными теперь содержится в отдельной строке, которую можно считать мгновенно с помощью FileReadLine;
2) разбор строки и вывод данных переделал, теперь для этого используются регулярные выражения;
3) сортировку данных в списке оставил, как было - GUICtrlRegisterListViewSort. Только поубирал некритические проверки и сократил код.

Результат:
Скорость построения списка возросла более, чем в 10 раз. Список из 500 страниц загружался раньше за 9 секунд, теперь - за 0,72 сек.
Всем спасибо, проблема пока решена.