控制台应用程序比 GUI 应用程序运行得更快吗？
我对编程世界比较陌生。我有几个性能问题：
控制台应用程序比具有图形用户界面的应用程序运行得更快吗？
像 C 和 Pascal 这样的语言比 C++ 和 Delphi 这样的面向对象语言更快吗？我知道语言速度更多地取决于编译器而不是语言本身，但是过程语言的编译器生成的代码比面向对象的编译器（包括可以生成 C 代码的 C++ 编译器）更快吗？
I am relatively new to world of programming. I have a few performance questions:
Do console apps run faster than apps with a graphical user interface?
Are languages like C and Pascal faster than object oriented languages like C++ and Delphi? I know language speed depends more on compiler than on language itself, but do compilers for procedural languages produce faster code than OO ones (including C++ compilers that can produce C code)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
简短回答：否
长答案：
在基于控制台的应用程序中，没有 GUI 线程需要重新绘制窗口并接受用户输入，因此从这个意义上说，控制台应用程序可能会稍微快一些（因为它少了一个占用 CPU 周期的线程）。然而，由于现代操作系统同时运行多个进程，无论如何，控制台应用程序仍然会与系统中的其他进程争夺 CPU，所以不会。
简短回答：否
长答案：
C 和 C++ 中的等效程序的执行大致相同。尽管编程语言当然可以在性能方面发挥作用，但通常您需要担心的主要问题是算法（您用应用程序逻辑表达的内容），而不是算法编码所用的语言。
Short answer: No
Long answer:
In a console based application, there is no GUI thread that needs to repaint the windows and accept user input, so in that sense, a console application may be slightly faster (since it has one fewer thread stealing away CPU cycles). However, since modern operating systems run multiple processes concurrently, anyway, a console application would still be contending for the CPU with other processes in the system, so no.
Short answer: No
Long answer:
Equivalent programs in C and C++ perform roughly the same. Although programming languages certainly can play a role in performance, generally the main thing you need to worry about is the algorithm (what you are expressing with your application's logic) and not the language the algorithm is coded up in.
Michael Aaron Safyan 已经给出了很好的答案。我想就为什么面向对象语言有时会与较慢的代码相关联做出一些贡献。
现实世界对我们程序员的要求不断迫使我们在更短的时间内编写更多的代码。对于非常熟练的程序员来说，汇编语言将赢得每一个速度记录，因为程序员准确地编写了机器需要执行的操作，而几乎没有其他的。在实践中，大多数编程不是用汇编程序完成的，因为它非常乏味且容易出错。编译语言使程序员的工作效率大大提高，因为它们让编译器处理大部分细节工作。
朝着同一方向进一步发展，Delphi 使用自动字符串：无论何时使用它们，它们都是“正确”的长度；如果连接两个字符串，则会生成一个新字符串，该新字符串的长度适合前一个字符串的组合。如果更改该字符串并使其变长，则会创建一个新字符串，并自动丢弃前一个字符串。作为一名 C 程序员，您可以预期程序将执行的操作并为较大的字符串分配足够的空间，因此您不必创建新字符串并丢弃旧字符串。因此，字符串的内存管理对于程序员来说是一种便利，但却是以牺牲一些 CPU 时间为代价的。
同样，面向对象允许您将相关数据组视为同质块，而不是字符串和数字。有时，并非需要所有这些信息，并且在低级 C 程序中，您可能不需要对象产生的某些操作和内存使用。这又是程序员便利性而非 CPU 速度的问题。
最后，一些接口被认为非常复杂，软件公司试图通过创建概念上更简单的处理的面向对象框架来使它们变得易于使用。您可以创建一个窗口对象，而不是调用打开窗口，这通常需要一些开销。在奇怪的开发中，软件公司和个人开发人员经常构建进一步的面向对象框架来隐藏或处理其他框架的复杂性。一些旧项目最终在原始功能之上使用了多层面向对象的框架，毫不奇怪，因为它们花费了大量时间进行自我管理，所以它们向客户展示了糟糕的性能，同时消耗了大量内存。
总之，面向对象代码有时会因为其使用方式而导致性能不佳。但特别是在 C++ 的情况下，语言中没有任何东西直接导致“慢”。
Michael Aaron Safyan has already given a very good answer. I'd like to contribute just a little bit on why object oriented languages sometimes can be associated with slower code.
Real-world demands on us programmers keep forcing us to write more code in shorter time. Given very skilled programmers, assembly language would win every speed record because the programmer codes exactly the operations the machine needs to perform, and very little else. In practice, most programming is not done in assembler because it's so tedious and error prone. Compiled languages make programmers a lot more productive because they let the compiler deal with much of the detail work.
Moving further in the same direction, Delphi works with automatic strings: They are the "right" length whenever they're used; if you concatenate two strings, a new one is produced that is the right length for the combination of the former strings. If you change that string and make it longer, a new string is created and the previous one is discarded automatically. As a C programmer, you could have anticipated what the program will do and allocated enough space for the larger string, so you would not have had to create a new one and discard the old one. So memory management for strings is a convenience for the programmer that's bought at the expense of some CPU time.
Similarly, object orientation allows you to treat groups of related data as homogenous chunks rather than strings and numbers. Sometimes not all of this information is needed, and in a low-level C program you might do without some of the operations and memory use that objects incur. It's once again a matter of programmer convenience over CPU speed.
Finally, some interfaces are considered very complicated, and software companies try to make them approachable by creating object-oriented frameworks with conceptually simpler handling. Rather than making the call to open a window, you may create a window object, usually with a bit of overhead. In a bizarre development, software companies and individual developers often build even further object-oriented frameworks to hide or handle the complexity of other frameworks. Some old projects end up with multiple layers of object oriented frameworks over top of the original functionality, and unsurprisingly, as they spend so much time managing themselves, they show poor performance to the customer while chewing up a lot of memory.
In summary, object oriented code is sometimes associated with poor performance because of how it's being used; but especially in the case of C++, there is nothing directly in the language that makes is "slow".
正如已经说过的，您的代码在控制台应用程序中的运行速度通常与在 GUI 应用程序中的运行速度一样快。
真正的区别是开销。在所有条件相同的情况下，GUI 应用程序是较大的 EXE，启动和关闭需要更多的时间，并且会消耗更多的资源。在应用程序运行时更新 UI 也是一种很好的形式，这可能会占用 CPU 密集型任务的周期。
但在大多数情况下这应该不重要。
As already said, your code will generally run equally fast in a console application as it will in a GUI application.
The real difference is overhead. All things being equal, GUI applications are larger EXEs that will take a little more time to start and close and will consume more resources. It's also good form to update the UI as the app is running, which may take cycles away from a CPU intensive task.
But it shouldn't matter in most cases.
由于缺少消息映射、窗口事件、GUI 线程等...控制台应用程序可能看起来比基于窗口的应用程序具有更快的性能。但对于您在控制台应用程序和基于窗口的应用程序之间进行选择，速度不应该是唯一的标准。您可能知道 Window 应用程序是“事件驱动编程”。
关于语言速度，我不能说只有 C 编译器可以生成更快的执行代码。事实上，C++ 编译器进行了大量代码优化，以最大限度地提高编译代码的速度。此外，OO 模型非常适合轻松编程、维护和扩展功能。
因此，根据需求使用适当的语言和技术
Since for the absence of Message maps, window events, GUI threads etc... console app might look like having faster performance that window based app. But for you to choose between console app and window based app, speed shouldn't be the only criteria. As you may be knowing Window apps are 'Event driven Programming'
Regarding language speed, I can't say only c compilers produces faster execution code. Infact c++ compilers does lot of code optimization for maximizing the speed of the compiled code. Also OO model are so good to program, maintain and extend the features with ease.
So use appropriate language and technology based on the requirement
不，即使相反也可能是正确的：
正如 Dav 在评论中所说，代码决定了应用程序的速度。对于编译器的另一端（生成的机器代码）也是如此。
一般来说，较新的编译器通常会生成更快的机器代码，因为它们利用先进的 CPU 功能并执行早期编译器中未找到的现代编译器优化。
例如，很可能创建一个 Pascal 应用程序，该应用程序在使用 Delphi（而不是旧的 Turbo Pascal 编译器）编译时运行得更快。
简而言之：不要仅仅因为旧的/原始的编译器看起来更轻量而使用它们。在大多数情况下，您不会获得任何性能。
No, even the opposite can be true:
As Dav said in his comment, the code desides how fast your application will be. This is also true for the other side of the compiler, the generated machine code.
In general newer compiler often produce faster machine code, because they utilize advanced CPU features and perform modern compiler optimizations not found in earlier compilers.
For example it's quite possible to create a Pascal application which runs faster when compiled with Delphi rather than an old Turbo Pascal compiler.
In a nutshell: Don't use older/primitive compilers just because they appear to be more lightweight. In most cases you'll not gain any performance.
由相同编译器生成的相同代码无论是在 GUI 应用程序还是控制台中运行，都会以相同的速度运行。此外，编译为 C++ 的 C 代码（假设它也兼容 C++）与编译为 C 的相同代码不会有显着差异。
但是，操作系统方面可能会影响性能，控制台应用程序除非在操作系统上被阻止或我/O 调用将消耗它们的整个时间片； GUI应用程序通常是事件驱动的，因此等待一个事件处理它，然后等待下一个事件；尽管您可能拥有与控制台应用程序类似的工作线程。此外，GUI 应用程序必然会花时间更新其更复杂的显示。但这些方面是在应用程序设计者和操作系统的控制之下，而不是编译器。
就 OOP 而言，它本质上并不慢，但有一些构造和架构可以导致更快速的应用程序开发以及更高的可维护性和鲁棒性，但这可能涉及性能的权衡。
The same code generated by the same compiler will run at the same speed regardless of whether it is running in a GUI app or a console. Moreover C code compiled as C++ (given that it is also C++ compliant) will not be significantly different if at all from the same code compiled as C.
However there are OS aspects that may affect performance, console apps unless blocked on an OS or I/O call will consume their entire time slice; GUI apps are generally event driven, so wait for an event process it, then wait for the next event; although you may have worker threads that operate similarly to console apps. Also a GUI app will necessarily spend time updating its more complex display. But these aspects are under the control of the application designer and the OS, not the compiler.
In terms of OOP, it is not intrinsically slower, but there are constructs and architectures that lead to more rapid application development and greater maintainability and robustness but which may involve a trade-off with performance.
这仅适用于您的第一个问题：
当控制台应用程序在图形环境（例如 GNOME 桌面或 Windows）中交互运行时，它们在终端窗口中执行此操作，而终端窗口实际上是 GUI 应用程序。因此，任何 GUI 成本（例如必须运行消息循环、不必分配 GUI 小部件等）都会简单地转移到托管环境。全屏运行控制台应用程序（文本模式屏幕）确实会减少 CPU 和您的设备之间的流量显卡，但任何速度改进都可以忽略不计。
然而，控制台 UI 的开发要容易得多，但代价是图形输出的灵活性较差。只需比较一下在 ncurses 中创建表单所需的工作量与使用 GTK 所需的工作量即可。
This only applies to your first question:
When console apps are run interactively in a graphical environment (say a GNOME desktop or on Windows), they do so within a terminal window which is actually a GUI app. So any GUI costs (like having to run a message loop, not having to allocate GUI widgets etc.) are simply transferred to the hosting environment. Running a console app full screen (text mode screens) does reduce the traffic between the CPU and your video card but any speed improvements will be negligible.
However, console UIs are far more easier to develop at the cost of being less flexible with graphical output. Just compare the effort it takes to create a form in ncurses vs. that required using GTK.
关于你的第二个问题，我想呼应迈克尔和卡尔，并添加另一个考虑因素 - 即自然厌恶真空，这适用于源代码。
由于高级语言允许人们使用更少的代码完成相同的工作，因此它们也允许人们使用相同的代码完成更多的工作，即使不需要。
因此，例如，您有时会看到这样的问题：
并询问这是否是循环开销的倍数，隐含地假设由于
<<只有两个字符，因此可以忽略不计。事实上，循环内的<<比循环多花费数千倍的周期。根据我的经验，包括我在内的几乎所有程序员都以多种方式完成了这一点，他们很感激用这么少的代码可以完成这么多事情，他们做了很多并且只是假设，如果他们这样做了，那就是必要的。因此，语言的级别越高，越重要性能调优技巧。
Regarding your second question, I want to echo Michael and Carl, and add another consideration - namely, that nature abhors a vacuum, and this applies to source code.
Since higher level languages allow one to do the same work with less code, they also allow one to do more work with the same code, even if it is not needed.
So, for example, you sometimes see on SO questions like this:
and asking if this times the loop overhead, implicity assuming that since
<<is only two characters, it is neglible. In fact the<<inside the loop takes thousands of times more cycles than the loop. In my experience, this is done in numerous ways by nearly all programmers including me, that they are thankful that so much can be done with so little code, that they do it a lot and just assume that, if they did it, it was needed.For that reason, the higher the level of the language, the more important is the skill of performance tuning.
谢谢大家在这个问题上帮助我
但我仍然很困惑我对 oo 语言的印象是它们有性能开销，因为它们的库臃肿。如果你使用 Blitz++ 库用 c++ 编写，它会运行得更快，如果不像 c 那么快，但可用于 c++ 的普通库使 c++ 比 c 慢，同样适用于 pascal 和 delphi 如果你使用 delphi7 而不是 delphi 2010 来编译你的程序，它将运行得更快，因为 delphi 2010 单位更重（警告：我没有将 delphi 7 与 2010 进行比较，也没有将 c++ 与 c 进行比较，这只是我的印象通过阅读在线论坛和语言与语言辩论创建的）你们可能会认为我疯了，但我更喜欢一个程序（甚至像文本编辑器一样小）完美运行，即使我的程序是要在超级计算机上运行，我仍然想优化我的代码，可能是我有强迫性人格障碍:)
thank you people for helping me out on this issue
but i am still confused my impession about oo languages is they have performance overhead because their libraries are bloated.if you write in c++ using Blitz++ library it will run faster if not as fast as c but normal libraries available for c++ make c++ slower than c,same applies for pascal and delphi if you use delphi7 instead of delphi 2010 to compile your program it will run faster cuz delphi 2010 units are heavier(warning : i havent compared delphi 7 to 2010 nor have i compared c++ to c its just my impression created by reading on line forums and language vs language debate) you people might think i am crazy but i'd prefer a program(even as minor as text editor) to run with perfection even if my programs were to run on a supercomputer i would still like to optimize the hell out of my code may be i have obsessive compulsive personality disorder :)