Do console apps run faster than GUI apps? [closed]

Question

I am relatively new to world of programming. I have a few performance questions:

1. Do console apps run faster than apps with a graphical user interface?

2. 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 ones (including C++ compilers that can produce C code)?

Answer 1

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.

Answer 2

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