控制台应用程序比gui应用程序运行得快吗?[关闭]

控制台应用比基于Windows的应用运行速度快吗

简短回答: 不
长回答:

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

C语言和PASCAL语言是否比面向对象语言(如C++和Delphi)更快?

简短回答: 不
长回答:

C和C++中的等效程序执行大致相同。尽管编程语言在性能方面确实可以发挥作用,但通常您需要担心的主要问题是算法(您用应用程序的逻辑表示的内容),而不是算法所用的语言。

迈克尔·亚伦·萨菲恩已经给出了一个很好的答案。我只想对为什么面向对象语言有时会与较慢的代码关联做一点贡献。

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

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

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

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

综上所述,面向对象的代码有时与性能的好坏有关,因为它是如何使用的,但尤其是在C++的情况下,语言中没有直接的“慢”。

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

真正的区别在于开销。所有的事情都一样,gui应用程序都是更大的exe,启动和关闭它们需要更多的时间,并且会消耗更多的资源。在应用程序运行时更新ui也是一种很好的形式,这可能会占用cpu密集型任务的周期。

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

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

关于语言速度,我不能说只有C编译器产生更快的执行代码。事实上,C++编译器进行了大量的代码优化,以最大限度地提高编译代码的速度。同时,oo模型也很容易编程、维护和扩展这些特性。

因此,根据需要使用适当的语言和技术

C语言和PASCAL语言是否比面向对象语言(如C++和Delphi)更快?

不,甚至恰恰相反:

正如戴维在评论中所说, 代码 停止应用程序的速度。对于编译器的另一端,即生成的机器代码,也是如此。

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

例如,使用delphi而不是旧的turbo-pascal编译器编译时,很有可能创建一个运行速度更快的pascal应用程序。

简而言之:不要仅仅因为旧的/原始的编译器看起来更轻量级就使用它们。在大多数情况下,你不会得到任何表现。

相同编译器生成的相同代码将以相同的速度运行,而不管它是在gui应用程序中运行还是在控制台中运行。此外,编译为C++的C代码(即使它也是C++兼容的),如果从C编译的相同代码中,则不会有很大的不同。

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

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

这只适用于您的第一个问题:

当控制台应用程序在图形环境(比如GNOME桌面或Windows)中以交互方式运行时,它们是在终端窗口(实际上是一个GUI应用程序)中运行的。因此,任何gui成本(如必须运行消息循环、不必分配gui小部件等)都只是转移到宿主环境中。全屏运行控制台应用程序( text mode 屏幕)确实减少了CPU和视频卡之间的通信量,但任何速度改进都可以忽略不计。

然而,控制台ui的开发要容易得多,代价是图形输出的灵活性要差得多。只需将在ncurses中创建表单所需的工作与使用gtk所需的工作进行比较。

关于你的第二个问题,我想重复迈克尔和卡尔的观点,并加上另一个考虑——即,自然厌恶真空,这适用于源代码。

因为高级语言允许一个人用更少的代码做同样的工作,他们也允许一个人用同样的代码做更多的工作, 即使不需要 .

例如,你有时会看到这样的问题:

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

并询问这是否乘以循环开销,隐式假设 << 只有两个字符,可以忽略。事实上 << 在循环中,所需的周期是循环的数千倍。以我的经验,这是由几乎所有的程序员包括我以多种方式完成的,他们感谢用这么少的代码可以完成这么多工作,他们 做很多事情 假设如果他们这么做了,那是必要的。

因此,语言水平越高, the more important is the skill of performance tuning .

谢谢你们在这个问题上帮助我 但我仍然困惑的是,我对OO语言的影响是因为它们的库是膨胀的,所以它们有性能开销。如果你用BLITIZ+++库编写C++,它运行得更快,如果不是C那么快,但是C++中的普通库使C++比C慢,同样适用于Pascal和DE。如果你使用Delphi 7而不是Delphi 2010来编译你的程序,它会运行得更快,因为Delphi 2010单元更重(警告:我还没有把Delphi 7和2010进行比较,我也没有把C++和C进行比较,这只是我在在线论坛和语言VS语言辩论中创建的印象)。可能会认为我疯了,但我更喜欢用一个程序(甚至像文本编辑器一样小)运行 完善 即使我的程序运行在一台超级计算机上,我仍然想优化我的代码,可能是我有强迫症:)