Я обнаружил, что все -vменьше и меньше использую флаг для многих приложений (особенно для таких простых вещей, как tarи cp). Однако когда я это сделал и, скажем, распаковал большой файл, это заняло бы больше времени, чем когда я не использовал этот -vфлаг.
Я предполагаю, что это потому, что терминал должен обрабатывать текст, и я заполняю любой буфер, который он может иметь. Но мой вопрос заключается в том, заставляет ли это приложение работать на самом деле медленнее или оно завершается за то же время, и то, что я вижу, - терминал пытается догнать?
tar xvf file.tar > /dev/nullпротивtar xf file.tar? Перенаправление на/dev/nullдолжно вывести ваш терминал из этого.stdoutиstderrони буферизуются строкой - это означает, что заполнение буферов не занимает много времени - это блокирующиеprintfвызовы (и с помощью вывода терминала расширения), которые занимают вечность.Ответы:
Да, запуск многословных замедлит работу ваших приложений.
Сколько зависит от приложения.
Каждый вывод на терминал потребует дополнительного времени обработки. В случае использования printf () или любой из его сестер, это довольно трудоемкий процесс.
Кроме того, терминал должен иметь дело с этими данными. Между приложением и терминалом существует ограниченный объем буферного пространства, и канал ввода-вывода будет блокироваться до тех пор, пока в указанном буфере не будет достаточно места для фактического вывода данных. Приложение, как правило, не сможет продолжить работу, пока происходит эта блокировка. 1
Кроме того, процесс отображения текста отладки на терминале будет занимать циклы обработки. Опять же, это зависит как от приложения (количество отладки), программы терминала (используемые шрифты, эффекты и т. Д.), Так и даже от используемого драйвера X Windows (аппаратное ускорение и т. Д.).
timeПрограмма может быть использована довольно точно определить , сколько времени команда заняла бежать. Запуск одной и той же программы дважды во времени, один раз с отладкой и один раз без, покажет вам, насколько это важно. Я бы предложил выполнить команду один раз перед выполнением тестов, чтобы убедиться, что кэширование одинаково для обоих тестовых прогонов команды. Вы не хотите искажать результаты, поскольку второй запуск выполняется намного быстрее, потому что большая часть данных была кэширована при первом запуске, теперь вы ...1 В случае многопоточного приложения фактически блокируется только поток, выполняющий выходные данные отладки.
источник
dir c:\/s/a. Вы можете увидеть изменение скорости, когда она полностью видна и частично покрыта. Вы не можете увидеть его ускорение при сворачивании, но оно определенно быстрее, хотя вам придется перезагрузиться, если вы хотите протестировать, чтобы обойти кэширование, которое в любом случае ускорит его, так как не будет для доступа к диску.Это зависит от того, какое приложение вы используете. Тем не менее, в целом можно сказать, что многословность замедлит работу большинства распространенных приложений Linux, поскольку они должны синхронизировать свои действия между стандартным выводом и вводом-выводом или пределами процессора.
источник
Использование
yesв качестве тестового примера на OS X 10.7, кажется, действительно имеет значение, если вы печатаете много вывода на терминал, как и следовало ожидать.Проанализировав это немного дальше, я запустил
yes5 секунд, в одном случае печатая вывод в терминал и сохраняя его в файл (сtee), в другом случае делая то же самое, за исключением перенаправленияstdoutна/dev/null:yes | tee yeslog_term & sleep 5 && killall yes && wc -l yeslog_termyes | tee yeslog_noterm > /dev/null & sleep 5 && killall yes && wc -l yeslog_notermСлучай 1. дает 2371584 строки, а случай 2. дает 136421376 строк, или в 57 раз больше. «Производительность»
yes(измеряемая количеством строк, которые она печатает за единицу времени) в этом случае, таким образом, в 57 раз ниже .Одно замечание здесь - это то, что я использовал
yesв связи с этимtee, что может немного повлиять на результаты, однако я думаю, что результаты все еще действительны.Еще одним признаком того, что программа замедлена, является то, что
yesпри работе во время вывода на терминал терминал использует около 100% ЦП иyesтолько около 37%, а при работеyesбез вывода на терминал он использует все 100% (это на нескольких основной машины, поэтомуyesмог бы использовать больше процессора, если это было возможно, за исключением того, что это было замедлено терминалом).источник
Легко просто ответить «да», это замедлит работу приложения. Но гораздо более верный ответ - это не имеет значения в 99% случаев.
Если ваше приложение выполняет какую-либо работу, которая на самом деле требует некоторой мощности процессора, шансы распечатать на экране несколько дополнительных строк текста с любой разницей близки к 0%.
На самом деле, вы можете легко сделать собственное суждение: если приложение извергает огромную стену текста, это может на самом деле стоить вам немного. Может быть.
источник
printf()безумно дорогоПодробный код обычно оценивается с помощью инструкции if, и каждый раз, когда он передает управление функции отображения, чем дольше он занимает, контекст может переключаться, тем больше прерываний.
Но это зависит от того, является ли ваш подробный код отдельным потоком, который время от времени просто проверяет состояние завершения, разница незначительна.
Этот вопрос может быть очень полезен благодаря вкладу опытных программистов stackoverflow. Предлагаю переехать :)
источник