Использование гигантского ИЛИ регулярного выражения неэффективно в Python? - PullRequest
0 голосов
/ 08 июля 2011

Простой вопрос, использует ли гигантское регулярное выражение неэффективно в Python. Я строю скрипт для поиска плохих файлов. У меня есть исходный файл, который содержит около 50 "подписей" до сих пор. Список имеет вид:

 Djfsid
 LJflsdflsdf
 fjlsdlf
 fsdf
 .
 .
 .

Реальных «консистенций» не существует, поэтому оптомизация списка путем удаления «дубликатов» или проверки «является ли одна запись подстрокой другой записи» мало что даст.

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

Чтобы ускорить процесс, я разобью список на 50 / n различных подсписков, где N - количество ядер, и у потока есть работа с несколькими записями списка.

Будет ли лучше использовать гигантское регулярное выражение re.search('(entry1|entry2|entry3....|entryK)', FILE_CONTENTS) или гигант for i in xrange(0,NUM_SUBENTRIES)...if subentry[i] in FILE_CONTENTS...?

Также это хороший способ многопоточности? Это Unix, поэтому несколько потоков могут работать с одним файлом одновременно. Будет ли доступ к диску в основном мешать мне до такой степени, что многопоточность бесполезна?

Ответы [ 3 ]

3 голосов
/ 08 июля 2011

Также это хороший способ многопоточности?

Не совсем.

Будет ли доступ к диску в основном мешать мне до такой степени, что многопоточность бесполезна?

Правильно.

Возможно, вы захотите присмотреться к multiprocessing.

  1. Рабочий Process должен выполнить OS.walk и поместить имена файлов в очередь.

  2. Пул рабочих Process экземпляров.Каждый получит имя файла из очереди, откроет его, проверит подпись и поместит результаты в «хорошую» очередь и «плохую» очередь.Создайте столько их, сколько нужно, чтобы процессор был загружен на 100%.

  3. Другой рабочий экземпляр Process может удалить из очереди хорошие записи и зарегистрировать их.

  4. Другой рабочий Process экземпляр может вывести из строя неправильные записи и удалить или переименовать или все, что должно произойти.Это может помешать os.walk.Можно записать их в файл «do this next», который обрабатывается после завершения os.walk.

0 голосов
/ 08 июля 2011

Не беспокойтесь об оптимизации.

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

0 голосов
/ 08 июля 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...