16

我对编程世界比较陌生。我有几个性能问题：

  1. 控制台应用程序是否比具有图形用户界面的应用程序运行得更快？

  2. 像 C 和 Pascal 这样的语言是否比像 C++ 和 Delphi 这样的面向对象语言更快？我知道语言速度更多地取决于编译器而不是语言本身，但是过程语言的编译器生成的代码是否比 OO 更快（包括可以生成 C 代码的 C++ 编译器）？

4

9 回答 9

31

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

简答：没有
长回答：

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

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

简答：没有
长回答：

C 和 C++ 中的等效程序的性能大致相同。尽管编程语言当然可以在性能方面发挥作用，但通常您需要担心的主要事情是算法（您用应用程序的逻辑表达的内容）而不是算法编码的语言。

于 2010-04-13T09:00:22.047 回答
5

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

现实世界对我们程序员的需求不断迫使我们在更短的时间内编写更多的代码。给定非常熟练的程序员，汇编语言将赢得所有速度记录，因为程序员准确地编写了机器需要执行的操作，而其他代码很少。实际上，大多数编程不是在汇编程序中完成的，因为它非常乏味且容易出错。编译语言使程序员的工作效率更高，因为它们让编译器处理许多细节工作。

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

同样，面向对象允许您将相关数据组视为同质块而不是字符串和数字。有时并非所有这些信息都是必需的，在低级 C 程序中，您可能不需要对象引起的一些操作和内存使用。这又是一个程序员方便而不是 CPU 速度的问题。

最后，一些接口被认为非常复杂，软件公司试图通过创建概念上更简单处理的面向对象框架来使它们易于使用。您可以创建一个窗口对象，而不是调用打开一个窗口，通常会产生一些开销。在一个奇怪的开发中，软件公司和个人开发人员经常构建更进一步的面向对象框架来隐藏或处理其他框架的复杂性。一些旧项目最终会在原始功能之上使用多层面向对象的框架，并且毫不奇怪，由于它们花费大量时间管理自己，它们在消耗大量内存的同时向客户展示了糟糕的性能。

总之，面向对象的代码有时会因其使用方式而导致性能不佳。但尤其是在 C++ 的情况下，语言中没有任何东西直接导致“慢”。

于 2010-04-13T09:18:31.353 回答
4

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

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

但在大多数情况下，这应该无关紧要。

于 2010-04-13T09:19:59.643 回答
2

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

关于语言速度，我不能说只有 c 编译器产生更快的执行代码。事实上，c++ 编译器做了很多代码优化，以最大限度地提高编译代码的速度。OO模型也非常适合轻松编程、维护和扩展功能。

所以根据需求使用适当的语言和技术

于 2010-04-13T09:03:13.797 回答
1

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

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

就 OOP 而言，它本质上并不慢，但有一些结构和架构会导致更快的应用程序开发以及更高的可维护性和健壮性，但可能涉及到性能的权衡。

于 2010-04-13T09:07:05.447 回答
1

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

不，甚至相反的情况也是如此：

正如 Dav 在他的评论中所说，代码决定了您的应用程序的速度。这也适用于编译器的另一端，即生成的机器代码。

一般来说，较新的编译器通常会产生更快的机器代码，因为它们利用先进的 CPU 功能并执行早期编译器中没有的现代编译器优化。

例如，使用 Delphi 而不是旧的 Turbo Pascal 编译器编译时，可以创建一个运行速度更快的 Pascal 应用程序。

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

于 2010-04-13T09:12:39.723 回答
0

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

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

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

于 2010-04-13T10:47:50.137 回答
0

关于你的第二个问题，我想回应 Michael 和 Carl，并添加另一个考虑因素 - 即大自然厌恶真空，这适用于源代码。

由于高级语言允许人们用更少的代码做同样的工作，它们也允许人们用同样的代码做更多的工作，即使它不是必需的。

因此，例如，您有时会在这样的 SO 问题上看到：

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

并询问这是否乘以循环开销，隐含地假设因为<<只有两个字符，所以可以忽略不计。事实上，<<循环内部的循环次数是循环的数千倍。根据我的经验，包括我在内的几乎所有程序员都以多种方式完成了这项工作，他们很庆幸可以用很少的代码完成很多工作，他们做了很多工作，只是假设，如果他们做到了，那就是需要。

因此，语言的层次越高，性能调优的技巧就越重要。

于 2010-04-13T13:19:58.407 回答
0

感谢人们在这个问题上帮助我，但我仍然很困惑我对 oo 语言的印象是它们有性能开销，因为它们的库过于臃肿。如果你使用 Blitz++ 库在 C++ 中编写，它会运行得更快，如果不如 C 快，但可用于 c++ 的普通库使 c++ 比 c 慢，如果您使用 delphi7 而不是 delphi 2010 编译程序，则同样适用于 pascal 和 delphi我是否将 c++ 与 c 进行了比较，这只是我通过阅读在线论坛和语言与语言辩论所产生的印象）你们可能认为我疯了，但我更喜欢一个程序（即使像文本编辑器一样小）完美运行即使我的程序要在超级计算机上运行，​​我仍然想优化我的代码可能是我有强迫性人格障碍:)

于 2010-04-14T06:19:55.037 回答