c/c++语言开发共享控制台应用程序运行速度比GUI应用程序快

控制台应用程序的运行速度比基于Windows的应用程

简答： 不
答案很长：

在基于控制台的应用程序中，没有GUI线程需要重新绘制窗口并接受用户输入，因此从这个意义上说，控制台应用程序可能会稍微快一点（因为它有一个较少的线程窃取CPU周期）。 但是，由于现代操作系统同时运行多个进程，因此控制台应用程序仍然会与系统中的其他进程竞争CPU，所以没有。

c和pascal这样的语言比c ++和delphi这样的面向对象语言更快吗？

简答： 不
答案很长：

C和C ++中的等效程序执行大致相同。 虽然编程语言肯定可以在性能中发挥作用，但通常您需要担心的主要问题是算法（您使用应用程序的逻辑表达的内容）而不是算法编码的语言。

Michael Aaron Safyan已经给出了一个非常好的答案。 我想简单介绍为什么面向对象的语言有时会与较慢的代码相关联。

对我们程序员的现实要求一直迫使我们在更短的时间内编写更多代码。 鉴于非常熟练的程序员，汇编语言将赢得每个速度记录，因为程序员准确编码机器需要执行的操作，而其他很少。 在实践中，大多数编程都不是在汇编程序中完成的，因为它非常繁琐且容易出错。 编译语言使程序员的工作效率更高，因为他们让编译器处理大部分细节工作。

进一步向同一方向移动，Delphi使用自动字符串：无论何时使用它们都是“正确”的长度; 如果连接两个字符串，则会生成一个新字符串，该字符串是前一个字符串组合的正确长度。 如果更改该字符串并使其更长，则会创建一个新字符串，并自动丢弃前一个字符串。 作为一名C程序员，你可以预料到程序会做什么，并为更大的字符串分配足够的空间，这样你就不必创建新的字符串并丢弃旧字符串。 因此，字符串的内存管理对于以牺牲一些CPU时间为代价购买的程序员来说是一种便利。

同样，面向对象允许您将相关数据组视为同质数据块而不是字符串和数字。 有时并不需要所有这些信息，而在低级C程序中，如果没有对象产生的某些操作和内存使用，您可能会这样做。 这又是程序员对CPU速度的便利问题。

最后，一些接口被认为非常复杂，软件公司试图通过创建具有概念上更简单处理的面向对象框架来使它们变得平易近人。 您可以创建一个窗口对象，而不是调用打开窗口，通常会产生一些开销。 在一个奇怪的开发中，软件公司和个人开发人员经常构建更加面向对象的框架来隐藏或处理其他框架的复杂性。 一些旧项目在原始function之上最终会有多层面向对象的框架，并且不出所料，因为他们花了很多时间来管理自己，所以他们在咀嚼大量内存时表现出糟糕的性能。

总之，面向对象的代码有时与性能不佳有关，因为它的使用方式; 但特别是在C ++的情况下，语言中没有任何东西可以“慢”。

如前所述，您的代码通常在控制台应用程序中的运行速度与在GUI应用程序中运行的速度相同。

真正的区别在于开销。 在所有条件相同的情况下，GUI应用程序是较大的EXE，需要更多的时间来启动和关闭，并将消耗更多的资源。 在应用程序运行时更新UI也是一种很好的forms，这可能需要一段时间才能完成CPU密集型任务。

但在大多数情况下，这应该不重要。

由于没有消息映射，窗口事件，GUI线程等…控制台应用程序可能看起来像基于窗口的应用程序具有更快的性能。 但是，要在控制台应用程序和基于窗口的应用程序之间进行选择，速度不应该是唯一的标准。 您可能知道Window应用程序是“事件驱动编程”

关于语言速度，我不能说只有c编译器产生更快的执行代码。 事实上，c ++编译器进行了大量的代码优化，以最大限度地提高编译代码的速度。 OO模型也很容易编程，维护和扩展function。

因此，请根据要求使用适当的语言和技术

c和pascal这样的语言比c ++和delphi这样的面向对象语言更快吗？

不，即使相反也是如此：

正如戴维在评论中所说， 代码要求你的申请有多快。 对于编译器的另一端，生成的机器代码也是如此。

通常，较新的编译器通常会生成更快的机器代码，因为它们利用了高级CPUfunction并执行了早期编译器中没有的现代编译器优化。

例如，很有可能创建一个Pascal应用程序，当使用Delphi而不是旧的Turbo Pascal编译器编译时，该应用程序运行得更快。

简而言之：不要使用旧的/原始编译器，因为它们看起来更轻巧。 在大多数情况下，你不会获得任何表现。

无论是在GUI应用程序还是控制台中运行，相同编译器生成的相同代码都将以相同的速度运行。 此外，编译为C ++的C代码（假设它也符合C ++），如果完全不同于编译为C的相同代码，则不会有显着差异。

但是，操作系统方面可能会影响性能，控制台应用程序除非在操作系统上被阻止或I / O调用将消耗其整个时间片; GUI应用程序通常是事件驱动的，所以等待事件处理它，然后等待下一个事件; 虽然您可能拥有与控制台应用程序类似的工作线程。 此外，GUI应用程序必须花时间更新其更复杂的显示。 但是这些方面都在应用程序设计者和操作系统的控制之下，而不是编译器。

就OOP而言，它本质上并不慢，但有一些结构和体系结构可以带来更快速的应用程序开发，更高的可维护性和健壮性，但这可能需要与性能进行权衡。

这仅适用于您的第一个问题：

当控制台应用程序在图形环境（例如GNOME桌面或Windows）中以交互方式运行时，它们会在终端窗口中实现，这实际上是一个GUI应用程序。 因此，任何GUI成本（如必须运行消息循环，而不必分配GUI小部件等）都只是转移到托管环境。 全屏运行控制台应用程序（ 文本模式屏幕）确实可以减少CPU和video卡之间的流量，但任何速度提升都可以忽略不计。

但是，控制台UI更容易开发，代价是图形输出的灵活性较低。 只需比较在ncurses中创建表单所需的工作量与使用GTK所需的工作量。

关于你的第二个问题，我想回应迈克尔和卡尔，并添加另一个考虑因素 – 即大自然憎恶真空，这适用于源代码。

由于更高级别的语言允许用较少的代码执行相同的工作，因此即使不需要，它们也允许用相同的代码执行更多的工作。

所以，举例来说，你有时会看到这样的问题：

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

并且询问这次是否是循环开销，隐含的假设因为<<只有两个字符，所以它可以忽略不计。 事实上， <<循环内部的循环比循环多几千倍。 根据我的经验，包括我在内的几乎所有程序员都可以通过多种方式完成这项工作，他们非常感谢能用如此少的代码完成这么多工作，他们做了很多事情而且只是假设，如果他们这样做了，那就是需要。

因此，语言水平越高，性能调整的技能就越重要 。

谢谢大家帮我解决这个问题，但是我仍然感到困惑我对oo语言的强迫是因为他们的库很臃肿而导致性能开销。如果你使用Blitz ++库在c ++中编写，如果没有c那么快它会运行得更快可用于c ++的普通库使c ++比c慢，同样适用于pascal和delphi如果使用delphi7而不是delphi 2010来编译程序它会运行得更快cuz delphi 2010单位更重（警告：我没有比较delphi 7到2010也没有我将c ++与c进行比较只是通过阅读在线论坛和语言与语言辩论创造的印象。你们可能会认为我很疯狂但是我更喜欢一个程序（即使像文本编辑器一样小）也能完美地运行，即使我的程序是在超级计算机上运行我仍然想优化地狱我的代码可能是我有强迫性人格障碍:)