我对编程世界相对较新。我有一些性能问题：
控制台应用程序的运行速度是否比具有图形用户界面的应用程序快？
像C和Pascal这样的语言比C ++和Delphi这样的面向对象语言更快吗？我知道语言速度更多地取决于编译器而不是语言本身，但是程序语言的编译器是否比OO编译器（包括可以生成C代码的C ++编译器）生成更快的代码？
答案 0 :(得分：31)
控制台应用程序比基于Windows的应用程序运行得更快
简答：否
答案很长：
在基于控制台的应用程序中，没有GUI线程需要重新绘制窗口并接受用户输入，因此从这个意义上讲，控制台应用程序可能会稍微快一些（因为它有一个线程可以减少CPU周期）。但是，由于现代操作系统同时运行多个进程，无论如何，控制台应用程序仍然会与系统中的其他进程竞争CPU，所以没有。
像c和pascal这样的语言比c ++和delphi等面向对象语言更快吗？
简答：否
答案很长：
C和C ++中的等效程序执行大致相同。虽然编程语言肯定可以在性能中发挥作用，但通常您需要担心的主要是算法（您使用应用程序的逻辑表达的内容）而不是算法编码的语言。
答案 1 :(得分：5)
现实世界对我们程序员的要求一直迫使我们在更短的时间内编写更多代码。鉴于非常熟练的程序员，汇编语言将赢得每个速度记录，因为程序员完全编码机器需要执行的操作，而其他很少。在实践中，大多数编程都不是在汇编程序中完成的，因为它非常繁琐且容易出错。编译语言使程序员的工作效率更高，因为他们让编译器处理大部分细节工作。
进一步朝着同一方向前进，Delphi使用自动字符串：无论何时使用它们都是“正确的”长度;如果连接两个字符串，则会生成一个新字符串，它是前一个字符串组合的正确长度。如果更改该字符串并使其更长，则会创建一个新字符串，并自动丢弃前一个字符串。作为一名C程序员，你可以预见到程序会做什么，并为更大的字符串分配足够的空间，所以你不必创建一个新的并丢弃旧的。因此，字符串的内存管理对于以一些CPU时间为代价购买的程序员来说是一种便利。
同样，面向对象允许您将相关数据组视为同质数据块而不是字符串和数字。有时并不需要所有这些信息，而在低级C程序中，如果没有对象产生的某些操作和内存使用，您可能会这样做。这又是程序员对CPU速度的便利问题。
最后，一些接口被认为非常复杂，软件公司试图通过创建具有概念上更简单处理的面向对象框架来使它们变得平易近人。您可以创建一个窗口对象，通常只需要一些开销，而不是调用打开窗口。在一个奇怪的开发中，软件公司和个人开发人员经常构建更加面向对象的框架来隐藏或处理其他框架的复杂性。一些旧的项目最终会在原始功能的基础上使用多层面向对象的框架，并且不出所料，因为他们花了很多时间来管理自己，他们在咀嚼大量内存时表现出糟糕的性能。
总之，面向对象的代码有时与性能不佳有关，因为它的使用方式;但特别是在C ++的情况下，语言中没有任何东西可以“慢”。
答案 2 :(得分：4)
如前所述，您的代码通常在控制台应用程序中的运行速度与在GUI应用程序中运行的速度相同。
真正的区别在于开销。在所有条件相同的情况下，GUI应用程序是较大的EXE，需要更多的时间来启动和关闭，并将消耗更多的资源。在应用程序运行时更新UI也是一种很好的形式，这可能需要一段时间才能完成CPU密集型任务。
但在大多数情况下这无关紧要。
答案 3 :(得分：2)
由于没有消息映射，窗口事件，GUI线程等...控制台应用程序可能看起来像基于窗口的应用程序具有更快的性能。但是要让您在控制台应用程序和基于窗口的应用程序之间进行选择，速度不应该是唯一的标准。您可能知道Window应用程序是“事件驱动编程”
关于语言速度，我不能说只有c编译器产生更快的执行代码。 Infact c ++编译器进行了大量代码优化，以最大限度地提高编译代码的速度。 OO模型也非常适合编程，维护和扩展功能。
因此，根据要求使用适当的语言和技术
答案 4 :(得分：1)
同一编译器生成的相同代码将以相同的速度运行，无论它是在GUI应用程序还是控制台中运行。此外，编译为C ++的C代码（假设它也符合C ++），如果完全不同于编译为C的相同代码，则不会有显着差异。
然而，操作系统方面可能会影响性能，控制台应用程序除非在操作系统上被阻止或I / O调用将消耗其整个时间片; GUI应用程序通常是事件驱动的，所以等待事件处理它，然后等待下一个事件;虽然您可能拥有与控制台应用程序类似的工作线程。此外，GUI应用程序必须花时间更新其更复杂的显示。但这些方面都在应用程序设计人员和操作系统的控制之下，而不是编译器。
就OOP而言，它本质上并不慢，但是有一些结构和体系结构可以实现更快速的应用程序开发，更高的可维护性和健壮性，但这可能需要与性能进行权衡。
答案 5 :(得分：1)
像c和pascal这样的语言比c ++和delphi等面向对象语言更快吗？
不，即使相反也是如此：
正如戴维在评论中所说，代码决定了你的申请有多快。对于编译器的另一端，生成的机器代码也是如此。
通常，较新的编译器通常会产生更快的机器代码，因为它们利用了高级CPU功能并执行了早期编译器中没有的现代编译器优化。
例如，很有可能创建一个Pascal应用程序，当使用Delphi而不是旧的Turbo Pascal编译器编译时，该应用程序运行得更快。
简而言之：不要因为它们看起来更轻巧而使用旧版/原始编译器。在大多数情况下，你不会获得任何表现。
答案 6 :(得分：0)
这仅适用于您的第一个问题：
当控制台应用程序在图形环境（例如GNOME桌面或Windows）中以交互方式运行时，它们会在终端窗口中实现，这实际上是一个GUI应用程序。因此，任何GUI成本（如必须运行消息循环，而不必分配GUI小部件等）都只是转移到托管环境。全屏运行控制台应用程序（text mode屏幕）确实可以减少CPU和视频卡之间的流量，但速度的提升可以忽略不计。
但是，控制台UI更容易开发，代价是图形输出的灵活性较低。只需比较在ncurses中创建表单与使用GTK所需的工作量。
答案 7 :(得分：0)
关于你的第二个问题，我想回应迈克尔和卡尔，并添加另一个考虑因素 - 即，大自然憎恶真空，这适用于源代码。
由于更高级别的语言允许用较少的代码执行相同的工作，因此它们还允许用相同的代码执行更多的工作，即使不需要，。
因此，例如，您有时会在这样的问题上看到：
time starttime = now;
for (i = 0; i < 1000000; i++){
cout << i;
}
cout << (now - starttime);
并且询问这是否是循环开销的时间，假设由于<<只有两个字符，因此可以忽略不计。事实上，循环内的<<需要比循环多几千倍的循环。根据我的经验，包括我在内的几乎所有程序员都可以通过多种方式完成这项工作，他们非常感谢用如此少的代码完成这么多工作，他们做了很多并且只是假设，如果他们这样做了，就需要它。
因此，语言级别the more important is the skill of performance tuning越高。
答案 8 :(得分：0)