Разве выполнение команд многословно делает их медленнее?

37

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

Я предполагаю, что это потому, что терминал должен обрабатывать текст, и я заполняю любой буфер, который он может иметь. Но мой вопрос заключается в том, заставляет ли это приложение работать на самом деле медленнее или оно завершается за то же время, и то, что я вижу, - терминал пытается догнать?

linux unix shell

— n0pe
источник

Вы пытались время, например, tar xvf file.tar > /dev/nullпротив tar xf file.tar? Перенаправление на /dev/nullдолжно вывести ваш терминал из этого.

— Бенджамин Баннье

3

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

— new123456

1

Если бы вы говорили о командах Windows, я бы точно сказал, что это правда :)

— Кокбира

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

— пользователь

31

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

Сколько зависит от приложения.

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

Кроме того, терминал должен иметь дело с этими данными. Между приложением и терминалом существует ограниченный объем буферного пространства, и канал ввода-вывода будет блокироваться до тех пор, пока в указанном буфере не будет достаточно места для фактического вывода данных. Приложение, как правило, не сможет продолжить работу, пока происходит эта блокировка. ¹

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

timeПрограмма может быть использована довольно точно определить , сколько времени команда заняла бежать. Запуск одной и той же программы дважды во времени, один раз с отладкой и один раз без, покажет вам, насколько это важно. Я бы предложил выполнить команду один раз перед выполнением тестов, чтобы убедиться, что кэширование одинаково для обоих тестовых прогонов команды. Вы не хотите искажать результаты, поскольку второй запуск выполняется намного быстрее, потому что большая часть данных была кэширована при первом запуске, теперь вы ...

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

— Majenko
источник

Большинство программистов учат это довольно быстро (Borland C в DOS);)

— Dragos

Конечно, если окно консоли скрыто (или даже частично закрыто), оно не будет влиять почти так же, как когда консоль видна. Откройте командную строку и выполните dir c:\/s/a. Вы можете увидеть изменение скорости, когда она полностью видна и частично покрыта. Вы не можете увидеть его ускорение при сворачивании, но оно определенно быстрее, хотя вам придется перезагрузиться, если вы хотите протестировать, чтобы обойти кэширование, которое в любом случае ускорит его, так как не будет для доступа к диску.

— Synetech

1

@Syn Мы говорим о Linux здесь.

— Majenko

1

@Matt это все еще действительный комментарий. Пожалуйста, будьте почтительны.

— nhinkle

@ Мэтт, дох! Я не заметил (Возможно, я отвлекся от комментария DOS.) В любом случае, Linux сильно отличается, но мне интересно, верно ли то же самое для него (видимые консоли с большим количеством прокрутки текста работают медленнее).

— Synetech

8

Это зависит от того, какое приложение вы используете. Тем не менее, в целом можно сказать, что многословность замедлит работу большинства распространенных приложений Linux, поскольку они должны синхронизировать свои действия между стандартным выводом и вводом-выводом или пределами процессора.

— Диого
источник

6

Использование yesв качестве тестового примера на OS X 10.7, кажется, действительно имеет значение, если вы печатаете много вывода на терминал, как и следовало ожидать.

Проанализировав это немного дальше, я запустил yes5 секунд, в одном случае печатая вывод в терминал и сохраняя его в файл (с tee), в другом случае делая то же самое, за исключением перенаправления stdoutна /dev/null:

yes | tee yeslog_term & sleep 5 && killall yes && wc -l yeslog_term
yes | 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мог бы использовать больше процессора, если это было возможно, за исключением того, что это было замедлено терминалом).

— Тим
источник

5

Легко просто ответить «да», это замедлит работу приложения. Но гораздо более верный ответ - это не имеет значения в 99% случаев.

Если ваше приложение выполняет какую-либо работу, которая на самом деле требует некоторой мощности процессора, шансы распечатать на экране несколько дополнительных строк текста с любой разницей близки к 0%.

На самом деле, вы можете легко сделать собственное суждение: если приложение извергает огромную стену текста, это может на самом деле стоить вам немного. Может быть.

— slarpspark
источник

3

-1 это просто неправда printf()безумно дорого

— Томас Бонини

1

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

— Slarpspark

@slarpspark: это не обязательно ничтожно мало, даже если мы уберем printf () из уравнения, поток байтов все равно должен пройти через bash, затем эмулятор терминала, затем эмулятор терминала должен был отобразить текст на экране. после анализа escape-символов и рендеринг текста не дешев, если выполняется со скоростью, с которой могли бы справиться некоторые подробные команды; и это было бы особенно дорого, если бы программа сбрасывала буфер вывода в каждой строке, поскольку это означает переключение контекста. При написании скриптов на Python я часто сталкиваюсь с тем, что удаление отпечатков в тесном цикле иногда может привести к 10 с к 1 с.

— Ли Райан

А как насчет команды, работающей по SSH, тогда даже если время процессора минимально, после того, как вы введете задержку в сети, несомненно, это существенно?

— ec2011

3

Подробный код обычно оценивается с помощью инструкции if, и каждый раз, когда он передает управление функции отображения, чем дольше он занимает, контекст может переключаться, тем больше прерываний.

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

Этот вопрос может быть очень полезен благодаря вкладу опытных программистов stackoverflow. Предлагаю переехать :)

— Dragos
источник