У меня есть вопрос о масштабируемости производительности с помощью xargs. В настоящее время у меня есть программа пакетной обработки, написанная на python с многопроцессорной обработкой и подпроцессом. Каждый процесс порождает независимый subprocess.popen() для выполнения внешней команды. Недавно я понял, что весь процесс можно переделать с помощью xargs. Тем не менее, мне интересно, стоит ли использовать xargs для обработки файлов размером более 10 000, поскольку я никогда раньше не делал чего-то такого масштаба только с помощью инструментов командной строки. Учитывая мой тест с небольшими наборами данных, на самом деле неплохая идея, если все, что я делаю, это пакетный запуск группы команд, поскольку это позволяет избежать многих циклов накладных расходов, связанных с модулями Python, но я хотел бы узнать больше от любого, кто может иметь больше опыта работы с xargs и python. В частности, есть ли какой-либо предел буфера, который мне нужно настроить, чтобы xargs потреблял большое количество входных данных? Спасибо.
производительность для многопроцессорной обработки xarg и python + подпроцесс
Ответы (1)
Программа xargs
соберет несколько аргументов из стандартного ввода и соединит их вместе, чтобы получилась одна длинная командная строка. Если имеется много-много-много аргументов, слишком длинных для одной командной строки, тогда он создаст и выполнит несколько командных строк столько, сколько необходимо.
Это означает меньше накладных расходов на запуск процессов и их завершение. Насколько это будет полезно для вас, зависит от того, как долго работают ваши процессы. Если вы запускаете какую-то ресурсоемкую программу, которая будет работать в течение получаса, время запуска процесса не будет иметь значения. Если вы запускаете программу, которая работает быстро, но запускаете только небольшое количество экземпляров, экономия опять же будет несущественной. Однако, если ваша программа действительно тривиальна и требует минимального времени выполнения, возможно, вы заметите разницу.
Судя по вашему описанию проблемы, это хороший кандидат для этого. 10К вещей с относительно короткой обработкой для каждой. xargs
может ускорить процесс.
Однако, по моему опыту, выполнение любой нетривиальной работы в сценариях оболочки приносит боль. Если у вас есть какие-либо имена каталогов или имена файлов, в которых может быть пробел, малейшая ошибка в заключении ваших переменных в кавычки приведет к сбою вашего сценария, поэтому вам нужно тщательно протестировать свой сценарий, чтобы убедиться, что он будет работать для всех возможных входных данных. По этой причине я делаю свои нетривиальные системные скрипты на Python.
Поэтому, если у вас уже есть ваша программа, работающая на Python, ИМХО, вы были бы сумасшедшим, если бы попытались переписать ее как сценарий оболочки.
Теперь вы все еще можете использовать xargs
, если хотите. Просто используйте subprocess
для запуска xargs
и передайте все аргументы через стандартный ввод. Это приносит все преимущества и не причиняет боли. Вы можете использовать Python, чтобы вставить байт NUL chr(0)
в конце каждого аргумента, а затем использовать xargs --null
, и он будет надежным с именами файлов, в которых есть пробелы.
В качестве альтернативы вы можете использовать ' '.join()
для создания собственных очень длинных командных строк, но я не вижу причин делать это, когда вы можете просто запустить xargs
, как описано выше.
xargs
илиsubprocess
будет настолько мала, что вы не заметите разницы. Или, если есть разница, это будет больше о том, какой из них лучше всего разделяет набор аргументов, а не о том, какой из них имеет наименьшие накладные расходы. Но, как говорит Кристиан Темус, зачем гадать, если можно на самом деле знать ответ? - person abarnert   schedule 25.10.2013