Приложения консоли работают быстрее, чем приложения с графическим интерфейсом?

Ответ 1

приложения консоли работают быстрее, чем приложение на основе Windows

Короткий ответ: Нет
Длительный ответ:

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

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

Короткий ответ: Нет
Длительный ответ:

Эквивалентные программы на C и С++ работают примерно одинаково. Хотя языки программирования, безусловно, могут играть определенную роль в производительности, как правило, главное, о чем вам нужно беспокоиться, это алгоритм (то, что вы выражаете с помощью логики приложения), а не язык, на котором закодирован алгоритм.

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

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

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

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

Ответ 9

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