Как получить прогресс os.walk в Python?

Question

У меня есть фрагмент кода, который я использую для поиска исполняемых файлов игровых файлов и возврата каталогов.Я действительно хотел бы получить какой-то индикатор прогресса относительно того, насколько далеко продвинулся os.walk.Как я могу добиться этого?

Я попытался выполнить сгенерированный код кода и оценить его, но это просто показывает, насколько глубоко сгенерированный код кода находится в дереве каталогов.

родовое слово

Answer 1

Я понял это.

Я использовал os.listdir для получения списка каталогов верхнего уровня, а затем использовал функцию .split для пути, возвращенного os.walk, вернув каталог первого уровня, в котором он находился в данный момент.

В результате у меня остался список каталогов верхнего уровня, в котором я мог найти индекс текущего каталога os.walk и сравнить полученный индекс с длиной списка, что дало мне процент завершения. ;)

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

Вот последний код моего прогресса:

родовое слово

А сейчас для целей отладки я делаю это дальше в коде:

родовое слово

Есть небольшой приятный способ избавиться от этого try / except ?; кажется, первая итерация пути мне ничего не дает ...

Answer 2

Это зависит от обстоятельств!

Если файлы и каталоги распределены более или менее равномерно, вы можете показать грубый процесс, предполагая, что каждый каталог верхнего уровня будет занимать одинаковое количество времени. Но если они распределены неравномерно, дешево об этом не узнать. Вы должны либо заранее приблизительно знать, насколько заполнен каждый каталог, либо вам нужно дважды выполнить os.walk целиком (но это полезно только в том случае, если ваша фактическая обработка занимает намного больше времени, чем сама os.walk).

То есть: предположим, у вас есть 4 каталога верхнего уровня, каждый из которых содержит 4 файла. Если вы предполагаете, что каждый каталог верхнего уровня занимает 25% прогресса, а каждый файл занимает еще 25% прогресса для этого каталога, вы можете показать хороший индикатор прогресса. Но если окажется, что последний подкаталог содержит намного больше файлов, чем первые несколько, ваш индикатор прогресса достигнет 75%, прежде чем вы узнаете об этом. Вы не можете исправить это, если узким местом является сам os.walk (а не ваша обработка) и это произвольное дерево каталогов (не то, где вы заранее знаете, сколько времени займет каждое поддерево).

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

Answer 3

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

Answer 4

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

Answer 5

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

родовое слово

но это займет некоторое время, и для этого вам, вероятно, понадобится индикатор прогресса ...

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

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

Answer 6

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

В Windows см. Все .В UNIX проверьте расположение.Не уверен насчет Mac, но уверен, что и там есть возможность.

Answer 7

как я сказал в комментарии, узкое место в производительности, вероятно, лежит за пределами функции locate.ваш returnMatches - довольно дорогая функция.Думаю, вам лучше заменить его следующим кодом:

родовое слово

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

Answer 8

Здесь мы думаем нестандартно ... что, если бы вы сделали это на основе размера :

• Используйте подпроцесс , чтобы запустить 'du -sb' и получить общий_размер вашего корневого каталога.
• По мере прогулки проверяйте размер каждого файла и уменьшайте его от total_size (давая вам unknown_size)
• pct_complete= (total_size - оставшийся_размер) / total_size

Мысли?

-aj

Answer 9

Одна оптимизация, которую вы могли бы сделать - вы конвертируете список файлов в набор при каждом вызове returnMatches, даже если он никогда не меняется.переместите преобразование в начало функции 'locate' и передайте набор на каждой итерации.

Answer 10

Что ж, было весело.Вот еще один глупый способ сделать это, но, как и все остальное, он вычисляет правильный прогресс только для однородных путей.

родовое слово