Консольные приложения работают быстрее, чем приложения для GUI? [закрытый]

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

Однако есть аспекты ОС, которые могут повлиять на производительность, консольные приложения, если они не заблокированы на Вызов ОС или ввода-вывода будет занимать весь их временной интервал; Приложения с графическим интерфейсом обычно управляются событиями, поэтому дождитесь обработки события, а затем дождитесь следующего события; хотя у вас могут быть рабочие потоки, которые работают аналогично консольным приложениям. Кроме того, приложение с графическим интерфейсом обязательно будет тратить время на обновление своего более сложного дисплея. Но эти аспекты находятся под контролем разработчика приложения и ОС, а не компилятора.

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

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

Реальная разница заключается в накладных расходах. При прочих равных условиях приложения с графическим интерфейсом являются более крупными EX-объектами, которые займут немного больше времени для запуска и закрытия и будут потреблять больше ресурсов. Также полезно обновлять пользовательский интерфейс по мере работы приложения, что может отнимать циклы у задачи с интенсивным использованием ЦП.

Но в большинстве случаев это не должно иметь значения.

Майкл Аарон Сафьян уже дал очень хороший ответ. Я бы хотел немного рассказать о том, почему объектно-ориентированные языки иногда ассоциируются с более медленным кодом.

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

Двигаясь дальше в том же направлении, Delphi работает с автоматическими строками: Они имеют "правильную" длину всегда, когда используются; если вы конкатенируете две строки, создается новая строка, длина которой соответствует комбинации прежних строк. Если вы измените эту строку и сделаете ее длиннее, будет создана новая строка, а предыдущая автоматически отбрасывается. Как программист на языке Си, вы могли бы предвидеть, что будет делать программа, и выделить достаточно места для более длинной строки, так что вам не пришлось бы создавать новую и отбрасывать старую. Таким образом, управление памятью для строк - это удобство для программиста, которое приобретается за счет некоторого количества процессорного времени.

Аналогично, объектная ориентация позволяет вам рассматривать группы связанных данных как однородные куски, а не как строки и числа. Иногда не вся эта информация нужна, и в низкоуровневой программе на C можно обойтись без некоторых операций и использования памяти, которые несут объекты. Это снова вопрос удобства программиста, а не скорости процессора.

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

В целом, объектно-ориентированный код иногда ассоциируется с низкой производительностью из-за того, как он используется; но, особенно в случае с C++, в языке нет ничего такого, что делает его "медленным".

Поскольку из-за отсутствия карт сообщений, событий окна, потоков GUI и т.д... консольное приложение может показаться более производительным, чем оконное. Но для выбора между консольным и оконным приложением скорость не должна быть единственным критерием. Как вы, наверное, знаете, оконные приложения - это "Event driven Programming"

Что касается скорости языка, я не могу сказать, что только компиляторы c производят более быстрый код. На самом деле компиляторы c++ делают много оптимизации кода для максимизации скорости компилируемого кода. Кроме того, ОО-модели так хороши для программирования, поддержки и расширения возможностей с легкостью.

Поэтому используйте соответствующий язык и технологию в зависимости от требований

являются ли такие языки, как c и pascal, более быстрыми, чем объектно-ориентированные языки, такие как c ++ и delphi?

Нет, может быть даже обратное:

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

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

Например, вполне возможно создать приложение на языке Pascal, которое будет работать быстрее при компиляции с помощью Delphi, чем старый компилятор Turbo Pascal.

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

спасибо, люди, что помогли мне в этом вопросе но я все еще не понимаю, что мое мнение о языках oo - у них накладные расходы на производительность, потому что их библиотеки раздуты.если вы пишете на c ++ с использованием библиотеки Blitz ++, он будет работать быстрее, если не так быстро, как c, но обычные библиотеки, доступные для c ++, делают c ++ медленнее, чем c, то же самое относится к pascal и delphi, если вы используете delphi7 вместо delphi 2010 для компиляции своей программы, он будет работать быстрее, потому что модули delphi 2010 тяжелее (предупреждение: я не сравнивал delphi 7 с 2010 и не сравнивал c ++ с c, это просто мое впечатление, созданное чтением онлайн-форумов и дискуссиями о языке и языке), вы можете подумать, что я сумасшедший, но я Я бы предпочел, чтобы программа (даже такая незначительная, как текстовый редактор) работала с совершенством , даже если бы мои программы запускались на суперкомпьютере, я все равно хотел бы чертовски оптимизировать свой код, может быть, у меня навязчивая идея компульсивное расстройство личности :)

Это относится только к вашему первому вопросу:

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

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

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

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

Так, например, вы иногда видите такие вопросы по SO:

time starttime = now;
for (i = 0; i < 1000000; i++){
  cout << i;
}
cout << (now - starttime);

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

По этой причине, чем выше уровень языка , тем важнее навык настройки производительности .