Самый быстрый алгоритм проверки наличия нестандартного файла

[ssslash]

Подскажите самый быстрый алгоритм для такой ситуации: есть папка с переодически добавляющимися файлами, файлы каких угодно типов в количестве 5-7 тысяч штук, имя у всех наподобии 06D763A311_D911AD0F_4313A292_001.exe, 06D763A311_D911AD0F_4313A292_002.jpg
Нужно узнать, появился ли в папке файл с нестандартным именем, то есть типа
06D763A311_ZZZZZZZZ_4313A292_006.exe, и в этом случае переместить его. Может есть что-то более быстрое, чем у каждого файла поочередно имя split`ом делить, а то ведь и директорий таких тоже не одна... Если можно, пример кода подкиньте, хотя за хитрый алгоритм тоже буду благодарен.

[Юстас]

Обычный FindFirstFile поддерживает поиск с *ZZZZZZZZ*

И ничего никакими сплитами делить не надо. Сразу имеешь результат. Плюс не перебираешь вручную всю папку.

[Sebas]

а в чём проявляется нестандартность? в отсутствии в каком то месте названии энтропии?.

Небольшй совет: если возможно, заиндексируй папку и ищи файлы в ней через WMI компоненты сервера индексирования. Это позволит тебе искать файлы с помощью WSQL тоесть примерно так
SELECT FROM Win32_File Where Name='***-zzzzzz-Я идиот! Убейте меня, кто-нибудь!"

поиск будет проходить на порядок быстрее.

>=win2k

[ssslash]

извиняюсь, неправильно объяснил я с этими ZZZZ... ночью писал, ступил как всегда... Это может быть просто любой набор символов. То есть в имени файла мне вообще ничего изначально не известно, он из трех разных ip-адресов строится, а в конце просто номер файла идет. Пока у всех файлов эти три адреса сопадают, мне ничего не нужно, а вот когда появляется файл, в котором какая-то часть имени изменилась хоть на один знак, мне надо его в отдельную папку перекинуть, причем в зависимости от того, в какой из трех частей имени изменение. Как раскидать я уже написал, но вот постоянно перебирать все эти файлы на предмет несоответствия друг другу...

[Cryonyx]

Обычный FindFirstFile поддерживает поиск с *ZZZZZZZZ*

А для тех, кто с бронепоезда : FindFirstFile - это через что?

[Eugenio]

Обычный FindFirstFile поддерживает поиск с *ZZZZZZZZ*

А для тех, кто с бронепоезда : FindFirstFile - это через что?

Это через API:
http://mech.math.msu.su/~vfnik/WinApi/f/findfirstfile.html

[tyomitch]

Обычный Dir тоже поддерживает поиск с *ZZZZZZZZ*
Через что FindFirstFile там, где достаточно Dir - комментировать не буду

[Eugenio]

Через что FindFirstFile там, где достаточно Dir - комментировать не буду

Это другой вопрос

[skiperski]

http://bbs.vbstreets.ru/viewtopic.php?t=5783

Первый раз перелопатить всю папку, а потом поставить сигналку и обрабатывать только каждый новый/изменённый файл.

[ssslash]

Спасибо за ответы.
А как ее быстрее всего перелопатить первый раз? Просто взять самый первый файл и сравнивать со всеми остальными значимую часть его имени с именами всех остальных файлов по очереди? или хитрость какая-нибудь есть?

[Юстас]

Через что FindFirstFile там, где достаточно Dir - комментировать не буду

Для тех кто в танке, стоящем на платформе бронепоезда:
Dir - это добраться до FindFirstFile через ж.
Т.к. Dir - это тот же FindFirstFile, обернутый ещё дополнительно всяким vb-хламом

[skiperski]

А чем не устраивает Split()? Достаточно быстрая функция.

Для теста создадим 5000 файлов:

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

Public Function test0()
   
    Dim ff As Long
    Dim i&, t!
   
    t = Timer()
    For i = 1 To 5000
        ff = FreeFile()
        Open "d:\4\06D763A311_D911AD0F_4313A292_" & Format$(i, "0000") & ".txt" For Output As #ff
        Close #ff
    Next
    Debug.Print Timer() - t, i
   
End Function

Immediate window

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

?test0
3,636719      5001

Тестируем:

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

Public Sub FileNameCompare(ByVal Path As String, ByVal Mask As String)
   
    Dim FileName As String
    Dim Mask2 As String
    Dim arr() As String
    Dim t!, i&
   
    t = Timer()
    FileName = Dir$(Path & "\*")
    Do While (Len(FileName))
        i = i + 1
        arr = Split(FileName, "_")
        Mask2 = arr(0) & "_" & arr(1) & "_" & arr(2)
        If (Mask2 <> Mask) Then
            Debug.Print FileName
        End If
        FileName = Dir$()
    Loop
    Debug.Print Timer() - t, i
   
End Sub

Public Function test()
    Call FileNameCompare("d:\4", "06D763A311_D911AD0F_4313A292")
End Function

Immediate window

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

?test
0,1015625     5000

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

Компутер: Intel Pentium 4, 1500 MHz, 256 KB RAM
ОС: Win2000, SP4, NTFS

[skiperski]

Т.к. Dir - это тот же FindFirstFile, обернутый ещё дополнительно всяким vb-хламом

Может быть, может быть, но... Просто протестируем.

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

Public Const MAX_PATH = 260

Public Type FILETIME
    dwLowDateTime As Long
    dwHighDateTime As Long
End Type

Public Type WIN32_FIND_DATA
    dwFileAttributes As Long
    ftCreationTime As FILETIME
    ftLastAccessTime As FILETIME
    ftLastWriteTime As FILETIME
    nFileSizeHigh As Long
    nFileSizeLow As Long
    dwReserved0 As Long
    dwReserved1 As Long
    cFileName As String * MAX_PATH
    cAlternate As String * 14
End Type

Public Declare Function FindFirstFile Lib "kernel32" _
    Alias "FindFirstFileA" (ByVal lpFileName As String, lpFindFileData As WIN32_FIND_DATA) As Long
   
Public Declare Function FindNextFile Lib "kernel32" _
    Alias "FindNextFileA" (ByVal hFindFile As Long, lpFindFileData As WIN32_FIND_DATA) As Long

Private Declare Function FindClose Lib "kernel32" (ByVal hFindFile As Long) As Long

Function StripNulls(OriginalStr As String) As String
    Dim p&
    p = InStr(OriginalStr, Chr(0))
    If (p) Then OriginalStr = Left$(OriginalStr, p - 1)
    StripNulls = OriginalStr
End Function

Public Sub FileNameCompare2(ByVal Path As String, ByVal Mask As String)
   
    Dim FileName As String
    Dim Mask2 As String
    Dim arr() As String
    Dim t!, i&, r&
    Dim FileData As WIN32_FIND_DATA
    Dim bIsDirectory As Boolean
    Dim hSearch As Long
   
    t = Timer()
    hSearch = FindFirstFile(Path & "*.*", FileData)
    r = hSearch
    Do While (r > 0)
        i = i + 1
        FileName = StripNulls(FileData.cFileName)
        If FileName <> "." And FileName <> ".." Then
            bIsDirectory = (FileData.dwFileAttributes And vbDirectory) = vbDirectory
            If (Not bIsDirectory) Then
                arr = Split(FileName, "_")
                Mask2 = arr(0) & "_" & arr(1) & "_" & arr(2)
                If (Mask2 <> Mask) Then
                    Debug.Print FileName
                End If
            End If
        End If
        r = FindNextFile(hSearch, FileData)
    Loop
    r = FindClose(hSearch)
    Debug.Print Timer() - t, i
   
End Sub

Public Function test()
    Call FileNameCompare2("d:\4", "06D763A311_D911AD0F_4313A292")
End Function

Проверяем:
Immediate window

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

?test
0,1289063     5003
0,140625      5003
0,1523438     5003
0,140625      5003

Во-первых, заметно увеличелось кол-во кода, во-вторых, скорость снизилась (даже самый лучший показалеть ниже, чем у варианта с Dir()).

Так что не всё коту масленица, что блестит.

[skiperski]

Только опубликуешь, как приходят идеи. Собственно какое имя файла ведь не важно, главное не по маске, тогда и Split() совсем не нужен. Точнее он понадобится, но уже при перемещении файла, а это уже другая задача.

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

Public Sub FileNameCompare(ByVal Path As String, ByVal Mask As String)
   
    Dim FileName As String
    Dim Mask2 As String
    Dim t!, i&, MaskLen&
   
    t = Timer()
    MaskLen = Len(Mask)
    FileName = Dir$(Path & "\*")
    Do While (Len(FileName))
        i = i + 1
        Mask2 = Left$(FileName, MaskLen)
        If (Mask2 <> Mask) Then
            Debug.Print FileName
        End If
        FileName = Dir$()
    Loop
    Debug.Print Timer() - t, i
   
End Sub

Immediate window

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

?test
0,046875      5000
5,078125E-02                5000
0,0390625     5000
5,078125E-02                5000
0,0390625     5000

Как следствие, результат улучшился минимум в 2 раза.

[Юстас]

skiperski

Скорость снизилась, потому что тестировать не умеешь. Сначала научись тестировать, а затем приводи в качестве аргумента цифры.

Из того времени, что работает приведенный тобой код, львиная уходит на вызовы аппендикса по имени StripNulls, на вызов функции split ( которая работает с типом Variant, это ни о чем не говорит?), InStr, Left$ и прочие разные Debug.Print'ы

Если не знаешь других способов, кроме кривого из ApiGuide, то не приводи его в пример.

[skiperski]

Скорость снизилась, потому что тестировать не умеешь. Сначала научись тестировать, а затем приводи в качестве аргумента цифры.

Покажи как надо.

Из того времени, что работает приведенный тобой код, львиная уходит на вызовы аппендикса по имени StripNulls, на вызов функции split ( которая работает с типом Variant, это ни о чем не говорит?), InStr, Left$ и прочие разные Debug.Print'ы

Если ты не обратил внимания, то и в первом варианте те же самые "прочие разные", за исключением StripNulls(), тоже вызываются и ровно в том же количестве. Без StripNulls() тестирумый вариант не работает. Чем предлагаешь заменить?

Если не знаешь других способов, кроме кривого из ApiGuide, то не приводи его в пример.

Да, код скопировал и немного причесал: подправил определение директории, переписал StripNulls. Стало работать несколько быстрее. Что там ещё можно оптимизировать? Покажи как надо.

[RayShade]

Юстас, я бы повежливее все таки постинги оформлял.

[skiperski]

Что там ещё можно оптимизировать?

Приходится всё самому

Перенёс обрезание имени файла в тело функции, убрал лишнюю проверку на "." и "..". И всё равно, не на много, но медленнее самого первого варианта. Да даже если было бы быстрее, то это не имеет никакого значения, т.к. время и так очень мало, и на пару миллисекунд быстрее или медленнее - рояля не играет, а код с Dir() компактнее, прозрачнее, переносимее и менее трудозатратный.

И всё ж таки хотелось бы увидеть оптимальный код. В отличие от умозрительных споров с Vitaly1, где доказать ничего невозможно в принципе из-за размытости постановки вопроса, неопределённости предмета спора и используемых определений, здесь всё очень просто и конкретно: код и результаты тестов в студию.

[Юстас]

skiperski

Нарисуй код, чтобы не пару десятков или сотен файлов было, а как у автора вопроса, несколько тысяч. Например, поиск в папке C:\Windows\ со всеми вложенными папками . А то и мерять нечего будет. Естественно с Dir$. О FindFirst\Next не заботься. Это уже готово. Пости свой код, я его добавлю в тест-проект и приаттачу.

[tyomitch]

Напомню, что о вложенности папок речи не шло. У автора вопроса поиск ведётся в одной папке.

[skiperski]

Нарисуй код, чтобы не пару десятков или сотен файлов было, а как у автора вопроса, несколько тысяч.

Читаем внимательно: специально для теста первая функция создаёт в папке "d:\4" 5000 файлов.

Например, поиск в папке C:\Windows\ со всеми вложенными папками . А то и мерять нечего будет. Естественно с Dir$. О FindFirst\Next не заботься. Это уже готово. Пости свой код, я его добавлю в тест-проект и приаттачу.

Красиво стрелки перевёл. Задача-то уже не та. Вложенные папки читать с помощью Dir() используя рекурсию не получится, а городить огород с простым циклом, буфером и прочей аттрибутикой не хоцца. Тем более, что, как уже я отмечал, пара-тройка миллисекунд рояля не играют.

Однако, речь не о сравнении двух методов, а о том, что ты обвинил меня в некорректном тестировании, хорошо хоть не в подтасовке результатов. Я спрашиваю: как этот тест написать корректно?

Далее обвинил в неправомочном использовании примера из ApiGuide. Вот весь код перед тобой. Я спрашиваю: чем он плох, как его можно оптимизировать? Предложи, напрмер, более быстрый вариант для StripNulls().

[Юстас]

Ну, ребяты, похоже в кусты?

Речь не идёт о вложенных папках. Речь о том, что быстрее, Dir или FindFirstFile Если есть папка с количеством файлов, достаточным для корректного измерения времени, чтобы время было не на уровне флуктуаций, то можно и без вложенных папок. Создадим тестовую папку с кучей файлов. Нет проблем.

И использование кода из API-Guida не является неправомерным. Уголовного Кодекса РФ никто не нарушал. Значит правомерно. Но неоптимально. Не надо путать понятия

И стрелки не переводил. Хоть сейчас.

Итак: речь о том, что быстрее: оптимизированная vb-фишка Dir или FindFirstFile в самом что ни на есть голом виде безо всякого рода оберток

Я предвижу крики, что всё это нечестно, поэтому сразу:
FindFirstFile в самом что ни на есть голом виде, без шелухи

И ещё: автор не вел речь о том, как пожиже да попроще да меньше букв набрать. Речь о скорости.
Хотя кода тоже меньше

Результат приводить не буду, машины разные, единственно FindFirst быстрее Dir'a

[hCORe]

Левая какая-то библиотека FindFirstFile.dll... Во-первых, размер 2,5 Кб. Во-вторых, PEiD выдал "Nothing found *". На асме писал?

[offtop]Кстати, Алекс спрашивает Юстаса, зачем тот пользуется гиперлокализованной версией языка - знаменитым Visual Basic 6.1 (в действительности 6.0 SP3) от именитого мастера Мыколы-пирата Я тоже когда-то на такой штуке писал, до того как нормальный диск купил. Меня поражала меткость перевода от Мыколы - командную кнопку он назвал "Коммандой". Точное выражение смысла Не перевелись ещё мастера на земле Русской - "главнОю процдуру" в окне настройки параметров проекта не переплюнул ещё никто [/offtop]

[Юстас]

hCORe, я вообще-то версии VB не считал, какой попался диск с пакетом VB, таким и пользуюсь Кстати диск приятель подогнал, с одной программерской конторы, думаю, что не должен быть он левым Или программеры, работающие на английскую фирму могут пользовать левый пакет? Ну конечно, с главнОю процедурой непорядок, а в остальном вроде усё пучком.

"Nothing found *" - блин, какой любопытный
В Debug'e писал

[skiperski]

Я предвижу крики, что всё это нечестно, поэтому сразу: FindFirstFile в самом что ни на есть голом виде, без шелухи

Может всё же код опубликуешь? Чтобы было о чём говорить?

И ещё: автор не вел речь о том, как пожиже да попроще да меньше букв набрать. Речь о скорости.

Только автору с твоего примера как с козла молока. Разве что удивиться как люди умеют и всё. Где полезный код на VB?

Хотя кода тоже меньше

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

Результат приводить не буду, машины разные, единственно FindFirst быстрее Dir'a

При первом запуске показали одинакове результаты, при последующих скрытое от наших глаз чудо работает ~ в 1.5-2 раза быстрее - ~0.15-0.19 и ~0.29-0.31 сек. соответственно.

Ещё раз повторюсь: время достаточно мало чтобы не вести спор о том какой из вариантов быстрее. Разница в 15 сотых секунды на 10 тысяч файлов - это не существенно. А вот отсутствие кода - это огромный минус. Что же ты там такое прячешь, что никак не можешь нам показать? Просто выложи код на VB и все вопросы сняты. И человеку поможешь и мы спасибо скажем.

[Юстас]

skiperski, есть устойчивый выигрыш FindFirst'a в 2 раза. Это факт.
Если убрать заполнение листбокса (в этом случае получается просто перебор всех файлов и возвращается их количество) то выигрыш достигает 3-х кратного размера (автору возможно и не нужно в лист запихивать). Это тоже думаю оспаривать смысла нет. Если надо, можно сделать и без заполнения.

Теперь о пользе для автора. Чтобы была польза, нужно конкретное описание задания, а не такое расплывчатое, как в вопросе в заголовке темы. Сделать под конкретную задачу - не проблема. Если знать что делать. Сейчас немного доработал либу. Ближе к вопросу автора: определяет просто наличие или отсутствие указанного файла. Если есть - результат отличный от нуля, если нет файлов, удовлетворяющих условию поиска - возвращается ноль. Пока автор конкретно не опишет задачу, трудно выдать готовое решение. Тем более, что ему несколько раз, с разными условиями надо выполнять поиск, как я понял.

О полезном коде на VB:

FileCount = FindFiles(ByVal TxtStartPath.Text, ByVal TxtPattern.Text, ByVal ListBox.hWnd)

Эта строка есть в тестовом проекте. И она заметно короче твоего куска с Dir, не так ли?

Если требуешь выложить внутренности моей либы, то будет справедливым, если ты тоже выложишь кишки msvbvm60.dll в той части, что касается Dir. И сравним, где и что и сколько. Отговорки о незнании, как это делается не принимаются. Сравнивать - так по-честному.

Вот что в моей либе, обычный FindFirstFile ,без шелухи:

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

FindFiles proc lpStartPath:DWORD, lpPattern:DWORD, hBox:DWORD
    LOCAL FindData                :WIN32_FIND_DATA
    LOCAL hFind                     :DWORD
    LOCAL szBuff[260]            :BYTE
   
    xor ebx,ebx
    invoke SendMessage,hBox,LB_RESETCONTENT,0,0
    invoke lstrcpy, addr szBuff,lpStartPath         
    invoke lstrcat, addr szBuff,lpPattern
    invoke FindFirstFile, addr szBuff, addr FindData
    .if eax != INVALID_HANDLE_VALUE
        mov hFind, eax
        .while eax != 0
            .if byte ptr FindData.cFileName != '.'
                invoke SendMessage,hBox,LB_ADDSTRING,0,addr FindData.cFileName
                inc ebx
            .endif
            invoke FindNextFile, hFind, addr FindData
        .endw
    .endif
    invoke FindClose, hFind
    invoke MessageBeep,0FFFFFFFFh
    mov eax,ebx
    ret
FindFiles endp

Теперь я жду листинга Dir из левой библы msvbvm60.dll
Если ты никогда в неё не заглядывал, то тебя ждет много сюрпризов

[Sedge]

2Юстас
Откуда столько нетерпимости? Здесь никто не спорит, что асм быстрее VB.
Но форум-то все-таки по Visual Basic. Вот если бы ты тот же результат получил оптимизацией VB-кода, тогда да... А так, имхо, твой способ - просто еще одно подтверждение большего быстродействия Ассемблера, не более.

[Юстас]

Sedge, есть такое выражение: quod licet Jovi, non licet Bovi. Возможно, что ты считаешь, (равно как и RayShade) что это есть правильно? У меня есть точка зрения, я её отстаиваю, на мой взгляд, вполне корректно, никого не оскорбляя, не применяя каких-то грязных и нецензурных выражений. Спору нет, я не поливаю елеем, но вполне корректно дискутирую с оппонентом.

Кроме того, никто не пытается доказать, что asm быстрее VB. Не подменяйте пожалуйста, понятия. Не надо передёргивать.
Есть VB-составляющая кода, есть asm-составляющая кода в dll.
У кода skiperski совершенно аналогично есть VB-составляющая и C-составляющая кода в msvbvm.

Так что никто не сравнивает VB с asm'ом. Сравниваются коды внутри обеих dll. По скорости работы. Думаю, что теперь более или менее понятно, о каком сравнении идёт речь.

P.S.
Если я невольно обидел skiperski, то я сожалею, что он воспринял это как оскорбление.

P.P.S.
О нетерпимости: Sedge, если внимательно посмотреть, то можно заметить, кто действительно проявляет нетерпимость, и ходит за мной по пятам из топика в топик и цепляется к каждому моему слову.

[skiperski]

skiperski, есть устойчивый выигрыш FindFirst'a в 2 раза. Это факт.

Уже устал повторять, что при таком незначительном времени - это НЕСУЩЕСТВЕННО!

Теперь о пользе для автора. Чтобы была польза, нужно конкретное описание задания, а не такое расплывчатое, как в вопросе в заголовке темы. Сделать под конкретную задачу - не проблема.

Т.е. ты собираешся специально для него сделать dll с одной единственной функцией и осчастливить его ей? А если условия задачи по ходу дела изменятся, что он будет делать с твоим чёрным ящиком? Или ты берёшь на себя обязательства постоянно переписывать эту библиотеку?

Ближе к вопросу автора: определяет просто наличие или отсутствие указанного файла. Если есть - результат отличный от нуля, если нет файлов, удовлетворяющих условию поиска - возвращается ноль.

И снова толку от такой быстрой функции ноль, т.к. обработка файла с несоответствующим маске именем должна быть внутри цикла обработки, а в твою либу этого не вставишь.

Пока автор конкретно не опишет задачу

Задача описана более чем конкретно

трудно выдать готовое решение.

Наконец-то! О том и речь чтобы дать не черный ящик с жёстко реализованной функциональностью, а каркас для дальнейшей его модификации.

О полезном коде на VB:

FileCount = FindFiles(ByVal TxtStartPath.Text, ByVal TxtPattern.Text, ByVal ListBox.hWnd)

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

Если требуешь выложить внутренности моей либы, то будет справедливым, если ты тоже выложишь кишки msvbvm60.dll в той части, что касается Dir.

Мы говорим о возможностях VB и давай оперировать понятиями в его рамках. Иначе такой алгоритм можно в железе прошить и рассуждать о быстродействии.

[skiperski]

Спору нет, я не поливаю елеем, но вполне корректно дискутирую с оппонентом.

Для нормальной дискуссии необходимо определить её тему и понятийные рамки в которых она будет проходить.
Тема: Что быстрее Dir() или FindFirstFile()/FindNextFile()?
Рамки: VB, т.е. инсталлируем VB и пишем. Всё.

У меня есть точка зрения, я её отстаиваю

Твоя точка зрения за рамками вопроса.

вполне корректно, никого не оскорбляя, не применяя каких-то грязных и нецензурных выражений.

Так и говорят лишь о нетерпимости, а не о грубости и хамстве.

Есть VB-составляющая кода, есть asm-составляющая кода в dll.
У кода skiperski совершенно аналогично есть VB-составляющая и C-составляющая кода в msvbvm.

Ага, а ещё у всех разные машины. Но это различие ты принимаешь во внимание: "Результат приводить не буду, машины разные", а различия языков - нет.

Так что никто не сравнивает VB с asm'ом. Сравниваются коды внутри обеих dll. По скорости работы. Думаю, что теперь более или менее понятно, о каком сравнении идёт речь.

Ещё раз повторюсь о реализации подобного алгоритма в железе. И что? Тоже будем сравнивать? Речь-то о VB.

Если я невольно обидел skiperski, то я сожалею, что он воспринял это как оскорбление.

Я так не воспринял. Резковато, но самое непонятное - нежелание слышать оппонента. Я про Фому, ты - про Ерёму. И получается какая-то бесконечная сказочка про белого бычка.

Лучше поинтересуюсь у автора топика, если ему всё ещё интересно здесь происходящее: Допомогло?