Do console apps run faster than GUI apps? [closed]_问答_开发者

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 12 years ago.

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 o开发者_JAVA百科nes (including C++ compilers that can produce C code)?

do console apps run faster than windows based app

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.

are languages like c and pascal faster than object oriented languages like c++ and delphi?

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 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".

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.

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

are languages like c and pascal faster than object oriented languages like c++ and delphi?

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.

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.

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:

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

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.

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 :)