Immor+al
Март 26, 2011 13:32:52
Я хочу написать утилитку, которая бы анализировала 10 000+ текстовых (*.java) файлов на наличие некоторого кода и выводила статистику\заменяла его.
Главная проблема - как максимально ускорить операции ввода\вывода:
1. Писать все на С
2. Писать частично на С в unix-style - отдельные утилитки, которые делают критическую к быстродействию работу, а их вызывать из Python.
3. Писать на Python 2, а наиболее критические методы реализовать на С
4. Писать все на Python 3
Алгоритм поиска будет как в тотал коммандере - рекурсивный обход папок только при первом запуске, потом используем построенное в файле\памяти дерево просканированной папки.
Писать все на С не хочется, да и гуи хочу сделать на PyQt4. С++ не люблю.
Какой вариант лучше?
Андрей Светлов
Март 26, 2011 13:41:52
Странная идея - ускорять на С операции с файловой системой
o7412369815963
Март 26, 2011 13:51:40
я на регексах делал обработку исходного кода на 1С (исходники 90Мб), открывал файлы через open(…).read()
работало все мгновенно
вот пример регекса
o7412369815963
Март 26, 2011 13:54:18
> Алгоритм поиска будет как в тотал коммандере - рекурсивный обход папок только при первом запуске, потом используем построенное в файле\памяти дерево просканированной папки.
это лишнее, список файлов можно моментально получить, например через os.walk.
основная нагрузка будет при обработке текста.
Immor+al
Март 26, 2011 14:40:44
>основная нагрузка будет при обработке текста.
Это понятно, что любой файловый i\o будет медленный.
Еще я слышал, что в Python 3 его оптимизировали. По сравнению с Python 2 разница будет заметной?
Андрей Светлов
Март 26, 2011 14:55:37
Не будет.
Не беспокойтесь о скорости раньше времени.
Immor+al
Март 26, 2011 15:05:31
>Не беспокойтесь о скорости раньше времени.
Допустим, вам нужно написать утилиту для data mining по простым алгоритмам.
На чем бы вы ёё писали?
Андрей Светлов
Март 26, 2011 15:12:43
На чем умею. Если говорить о питоне - предпочел бы третий. По эстетическим соображениям.
lorien
Март 26, 2011 16:38:12
Кстати, уже есть подобная утилитка
https://bitbucket.org/lorien/srОптимизацией там мы не занимались - текущим нуждам полностью удовлетворяет. И ещё она построково работает т.е. поиск регекспа ведёт только в контексте одной строки файла.
doza_and
Март 26, 2011 21:09:27
По поводу -
1 писать все на c:
делал сканер файла на perl и на гольном “c”, (в “с” было достаточно strstr()) перл оказался чуть чуть быстрее
2 имел дело с системой где данные хранились в 177000 файлах (три уровня вложения директорий ntfs windows xp файлы от 1 до 100к ) open был по времени гораздо дороже чем чтение данных (двоичное)