Реально ли ускорить Instr?

[|kerish|]

У меня в разработке некой утилиты возникла проблема с быстродействием алгоритма использующего InStr и функцию преобразования Hex в строку.

Реально ли ускорить Instr?

или ускорить функцию перевода Hex в строку?

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

Private Function HexToStr(ByVal Data As String) As String
Dim i As Long
If Len(Data) Mod 2 Then
HexToStr = vbNullString
Else
HexToStr = Space(Len(Data) \ 2)
For i = 1 To Len(Data) Step 2
Mid(HexToStr, i \ 2 + 1, 1) = Chr("&H" & Mid(Data, i, 2))
Next i
End If
End Function


[GSerg]

Для начала, прекрати использовать Variant...

[|kerish|]

Да, кстати, повторюсь.
То ли на этом форуме, то ли где-то ещё какой-то человек выкладывал или давал ссылку на библиотеку для офигенно быстрой работой со строками.

[|kerish|]

GSerg А где у меня Variant? Если ты в общем имеешь ввиду, то у меня Variant-ов нету и везде прописан Option Explicit.

[GSerg]

А у тебя везде Variant, во всех функциях работы со строками.

[BV]

Mid$, Left$, Space$...

[Antonariy]

http://www.xbeat.net/vbspeed/index.htm
Однако instr им побить не удалось...

[alibek]

InStr им и не побить.
Он компилируется непосредственно в машинный код; при использовании бинарного сравнения непосредственно в инструкцию процессора.

[alibek]

Для начала, прекрати использовать Variant...

И кроме того, не стоит использовать конкатенцию строк.
Chr("&H" & Mid(Data, i, 2)) следует заменить на работу непосредственно с кодами символов (Asc(...)*16+Asc(...)).

[alibek]

P.S. Не наезд, а просто размышления на тему.
|kerish|, ты меня поражаешь. Выпускаешь системные утилиты, которые по твоим заверениям превосходят всех LavaSoft, Касперских и Симантеков, вместе взятых, и вместе с тем используешь такие дилетантские решения.
Mid(HexToStr, i \ 2 + 1, 1) = Chr("&H" & Mid(Data, i, 2)) ведь потом появилось, вначале у тебя было HexToStr = HexToStr & Chr("&H" & Mid(Data, i, 2)).

[Antonariy]

InStr им и не побить.
Он компилируется непосредственно в машинный код; при использовании бинарного сравнения непосредственно в инструкцию процессора.

А instrrev побили. И их вариант работает быстрее instr.

[alibek]

InStrRev да, поскольку он вызывается из MSVBVM. Я говорил только о InStr.

[alibek]

А instrrev побили. И их вариант работает быстрее instr.

А где ты нашел InStrRev? Я что-то найти не смог.

[Antonariy]

В секции vb6->vb5

[|kerish|]

alibek Kerish Antivirus - не превосходит Касперского по эффективности, а лишь по скорости, Kerish Doctor - реально превосходит конкурентов лишь из-за того, что знает на порядок больше проблем.

to All Короче скорость усилить так и не удалось. Файл в 20 кб сверяется с базой в 32219 сигнатур за 2 секунды. А файл в 40 кб - 5 секунд, файл в 100 кб 13 секунд. Поэтому скорость критически низкая

[alibek]

Я бы советовал грузить файлы в байтовые массивы (порциями по 500-1000Кб), и искать внутри них, только не InStr (она не работает с массивами), а через WinAPI.

[|kerish|]

Интересная мысль.
А ты думаешь это ускорит алгоритм? Ведь загрузка файлов в массивы + поиск в них могут дать ту же скорость.

[alibek]

Я думаю, что основные потери скорости у тебя возникают из за преобразования Binary <> String. Если ты избавишься от этого преобразования, то думаю, скорость повысится.

[Antonariy]

Я бы советовал грузить файлы в байтовые массивы (порциями по 500-1000Кб), и искать внутри них, только не InStr (она не работает с массивами), а через WinAPI.

InStr как раз таки преобразует строку в массив в режиме vbBinaryCompare (по умолчанию) и проверяет его, поэтому ее побить и не удалось.

[alibek]

Antonariy, я говорил не об этих преобразованиях (хотя и тут есть лишняя пара Bin-Str-Bin), а о Hex-дампе, который прописан в файлах-сигнатурах и который преобразуется из Hex-дампа в двоичный дамп.

[uhm]

InStr им и не побить.

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

[alibek]

Откуда такая уверенность? У тебя есть исходники InStr?

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

[alibek]

...что возможно написать функцию, которая в некоторых случаях будет работать быстрее.

Что может быть быстрее однотактовой команды?
Если, разумеется, меня умная книжка не обманула.

[uhm]

Есть однотактовая команда, которая в последовательности байтов ищет заданную подпоследовательность? Или я просто не понял, о чем разговор идет?

[tyomitch]

Есть однотактовая команда, которая в последовательности байтов ищет заданную подпоследовательность? Или я просто не понял, о чем разговор идет?

SCASW - по моему (жутко старому) мануалу, 6 тактов на итерацию.
Может, уже и до одного дооптимизировали.

[uhm]

Почитал в Яндексе про SCAS(B,W) - вроде бы, они умеют искать в строке только один байт или одно слово, а не подстроку в строке. Если это так, и именно это имел в виду alibek, то все, что я говорил, остается в силе.

[tyomitch]

Думаю, что это именно так, хотя исходников компилятора VB, конечно, не видел

Что касается "оптимальных алгоритмов поиска подстроки в строке" - то это очень животрепещущая тема, по которой афаик даже сейчас защищаются диссертации. Некоторые алгоритмы есть на http://algolist.manual.ru/search/esearch/index.php , но "самого оптимального", конечно, нет.

2kerish: есть подозрение, что ускорить HexToStr будет гораздо легче, чем мучаться с поиском подстроки. Например, перевести Data сразу в байтовый массив, и работать с ним.

[GSerg]

Да работает instr с массивами... с байтовыми... И instrb с ними работает...

[tyomitch]

GSerg, или я не понял твоей мысли, или ты не понял что у kerish нету байтового массива, а есть строка в хексе.

[GSerg]

Угу...
Просто 90%, что он таким образом читает файл в память...

Потому что см. задачу - сравнить содержимое файла с базой сигнатур...
Читает ведь наверняка в строку и то, и другое...