Оптимизация загрузки текстового файла

[hCORe]

Загрузка и обработка текстового файла (разделитель - запятые) с добавлением записей с иконками в TreeView происходит подозрительно медленно. На моей машине тест показал 549 мс (в exe файле). В идеале вся операция должна идти лишь 1/10 этого времени. Программа очень критична к производительности (по крайней мере, во время загрузки.) Код теста прилагается. Кто что посоветует?

[xolod]

1) Для начала - отключи на время загрузки перерисовку treeview (SendMessage TreeView.hwnd, WM_SETREDRAW, 0, 0), после загрузки ессесно включи
2) Убери все DoEvents, если таковые имеются
3) Split (впрочем как и vb'шные функции, ОЧень медленная, так что..)
4) Не пиши лог

[Ennor]

xolod, это не прокатит - басиковое дерево игнорирует посланные ему WM_SETREDRAW. Я в свое время столкнулся с этим, и кажется, так и не решил. Можно попробовать посылать ему это сообщение дважды подряд - тогда иногда срабатывает. По крайней мере, иногда...

[alibek]

А если TreeView сделать невидимым? Во всяком случае это работает на ListBox и ListView.

[Ennor]

Если невидимым, то так:

...
DoEvents
Me.tvw_Tree.Visible = False
DoEvents
...
Иначе может не сработать.

[alibek]

Во-первых, измени ReDim Preserve.
Советую примерно такой алгоритм:

Код: Выделить всё

Dim arr(), C As Long, N As Long
C = 0
N = 0
ReDim arr(0)
Do
  ...
  If ... Then
    C = C + 1
    If C > N Then ReDim
      N = N + 100
      ReDim Preserve arr(0 To N)
    End If
    arr(C) = ...
  End If
Loop
ReDim Preserve arr(0 To C)


ReDim Preserve не самая быстрая операция и количество ее выполнений лучше уменьшить.

Правда я это сделал и особого быстродействия не заметил, но все же загрузка идет немного быстрее.

Все строки, которые используются, замени на константы. Т.е. не "", а vbNullString, не ";", а vbStrSemicolon (а в модуле Const vbStrSemicolon As String = ";") и т.п. Насчет скорости не уверен, а память сэкономишь.

Что-то надо делать с DrawSkinIcon. Советую все иконки загрузить в массив StdPictures и присваивать значки из массива. Еще лучше заменить на API.

Ну и я бы пересмотрел способ заполнения дерева. Каждый раз искать в коллекции ключевой элемент, к которому добавляются остальные элементы... Лучше объяви массив Node и храни их в памяти все то время, пока идет заполнение списка.

[alibek]

Ennor, помоему когда окно делается видимым/невидимым, оно перерисовывается само, без принудительного рефреша.

[Ennor]

Ennor, помоему когда окно делается видимым/невидимым, оно перерисовывается само, без принудительного рефреша.

Ну да, как правило. Во всяком случае, InvalidateRect() для него всяко вызывается. Я просто не понял - ты о чем именно?

[alibek]

Ennor, а я видимо не понял, зачем DoEvents
Без него у меня все работало.

[Ennor]

Ясно А вот у меня не работало, причем гораздо более важным оказывался первый DoEvents, нежели второй. Видимо, тачка слишком слабая...

[Ruslan Demidow]

xolod, это не прокатит - басиковое дерево игнорирует посланные ему WM_SETREDRAW. Я в свое время столкнулся с этим, и кажется, так и не решил. Можно попробовать посылать ему это сообщение дважды подряд - тогда иногда срабатывает. По крайней мере, иногда...

Может быть и неверно, но Эпллман писал, что WM_SETREDRAW контролы принимают к сведению, если для работы с контролами использовать тоже сообщения (т.е. API).
Любое родное (бейсиковое) действие типа AddItem, RemoveItem, NоdeAdd объявляет регион недействительным и принудительно заставляет его перерисовываться. Поэтому и не срабатывает WM_SETREDRAW.

[Ennor]

Не скажи: RTB прекрасно блочит перерисовку, даже если с ним после этого работать на уровне .SelForeColor . Это только дерево такое... деревянное.

[Ruslan Demidow]

Не скажи: RTB прекрасно блочит перерисовку, даже если с ним после этого работать на уровне .SelForeColor . Это только дерево такое... деревянное.

Согласен. Но списки, комбобоксы и т.п. при использовании бейсиковских методов ведут себя именно так как я сказал.

[xolod]

Так, проверил, деревяшка действительно не блочиться

Еще варианты:

1) Заюзать (блочит все окно нафик)

Код: Выделить всё

Declare Function LockWindowUpdate Lib "user32" Alias "LockWindowUpdate" (ByVal hwndLock As Long) As Long


2) Использовать treeview, что на vbAccelerator лежит (его правда немного поправить надо), работает быстрее.

[Ennor]

Почитал про LockWindowUpdate() - суровая штука, ничего не скажешь. Проверь, действительно, вдруг поможет...

[hCORe]

Помогло, но немного... Теперь грузит данные не 549, а 312 мс. Но надо-то 50 мс
Вот, выкладываю. И повторяю: DoEvents убрать, к сожалению, нельзя. И все тут

[Юстас]

For lngL = 0 To UBound(arrLines) - 1 - зачем раз за разом вычислять размерность массива ?
j = UBound(arrLines) - 1
For lngL = 0 To j
================================================
- зачем раз за разом в цикле проверять длину переменной, которая не меняется?
If Len(Trim$(Ln)) <> 0 Then

End If

Вынеси этот If...End If за цикл

================================================
Dim sc As Long, sx As Long - зачем опять же в цикле раз за разом определять переменные?
Тем более если не используешь их ?

================================================
If Mid$(CDir, Len(CDir), 1) <> "\" Then CDir = CDir & "\" - и ещё раз зачем в цикле раз за разом вставлять бэкслэш в строку, которая не меняется?

А вообще для VB задача непосильная, имхо. 50 мс нереально для этого алгоритма. Ради эксперимента смоделировал чтобы ни одна иконка не была добавлена в TreeView, и результат получился 47 мс. Это просто пустые операции по подготовке к загрузке рисунка.
За оставшиеся 3 мс ни в какой TreeView ты ничем не загрузишь иконки. Мне так кажется. И никакой LockWindowUpdate не поможет.

[marvan]

основное время (381ms относительно общего 516ms) съедает эта строка
iml2.ListImages.Add , "__key@" & CStr(lngL), LoadPicture(ml2)
Так что treeview тут не при чём.
А я ведь в своё время рекомендовал грузить графику из ресурсов.