Знаю, тема ламерская... Но стоит ребром. На небольшой алгоритм поиска файлов в подкаталогах (один, хочу заметить), в инете нарыл кучу вариаций... При чем далеко не самых эфективных, если сказать, что по скорости уступают даже виндузовскому поиску... =// Думаю, все в свое время реализовывали данный алгоритм, и все по своему... Кому не жалко, и кто хочет поделиться с миром своими разработками, огромнейшая просьба либо детально скинуть алгоритм, либо кусочек кода... Заранее благодарен. P.S. Некоторые могут подумать, что у меня у самого с реализацией поиска дела идут туго... Кстати, правильно подумают.
Алгоритм действительно сложнейший... Код (Text): FindAll: FindFirstFile(*.*) do if(Directory?) { cd name FindAll cd .. } while(!FindNextFile()) Какая-то смесь *.c и *.bat получилась
Наверное, все-таки вопрос был в другом: допустим, если искать все файлы типа BAT и BMP, то можно вместо поиска по маске *.* искать *.B* или даже *.B??. Сам я статистики по скорости поиска файлов не собирал и не могу сказать, даст ли такая оптимизация маски сколь-нибудь заметный эффект, однако не прочь был бы узнать, дает ли преимущество "усовершенствование" маски и использование вопросиков вместо звездочек.
Имхо преимущество от оптимизации поиска можно получить, при грамотной реализации поддержки индексации файлов (NTFS такое поддерживает). Это с расчетом на то что поиск работает, по содержимому файлов. Еще есть вариант - регулярное обновление некоторой структуры файлов (проход по всем изменившимся папкам) в памяти приложения, в которой налажен эффективный поиск по маске. То есть при обращении на поиск информации - API функции не мучаются, а сканируется в таблице (по маске или без оной), что на ассемблере может быть реализовано очень эффективно (хотя при этом, если сама таблица не обновляется в Real-Time, некоторые файлы могут быть незамечены, или найдены уже удаленные файлы). Еще вариант - попробывать многопоточный поиск в различных папках, может на гипертрединговых и не только процессорах это даст прирост в производительности.
Сначала нужно определиться с тем, что за файл ищем, а уж потом оптимизировать. Можно предусмотреть "белый список" и "черный список" имен подкаталогов для конкретного файла, поиграться с приоритетами поиска по атрибутам доступа к папке и датам последнего доступа. В конце, концов, сделать само-обучаемую систему определения вероятности нахождения файла в конркетном подкаталоге А сам поиск выполнять при многпоточной организации - в овтет на каждый найденный подкаталог программа стартует новый поток с поиском в этом каталоге, потоки синхронизируются с диспечтером (программы), который уж и ввыставляет приоритеты При самом безмозглом многпоточном алгоритме мат ожижание от среднего время поиска уменьшится Это, так, вольные рассуждения...
Кстати, немного не в тему, но надо стараться избегать рекурсии, а обходиться одними циклами - рекурсия жрет ой как много памяти.
microsoft indexing service -ищем не по диску а по индексированной базе файлов. мс его и использует. есть начиная с вин2000 читай спеки по xfs filesystem -более быстрой я не видел в любом случае тебе нужно создавать базу файлов(индекс) а потом по ней искать.
