views:

853

answers:

9

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

+25  A: 
Michael Aaron Safyan
ACtually, in a console based application, the GUI thread is just hidden from you. But the pixels still need to be drawn to the screen, and the console window can be dragged around, so obviously the input is handled somehow.
MSalters
@MSalters, a console application can also be run in the background with I/O redirected, in which case there would be no GUI thread. Although, yes, the console window, if there is one, needs to repaint and accept I/O.
Michael Aaron Safyan
Quick and dirty comment: Delphi Object code is little bit slower than Delphi procedure code, because of the "self" pointer (must be stored in CPU register or stack) and getting slower if you use many function overrides. You can see this when you look at the generated code in Delphi (CPU view, CTRL-ALT-C).C++ has the same: if you use object code instead of procedural code (like normal C) it has more overhead because of object inheritance etc. For embedded software, sometimes C must be used because C++ is too slow c.q. too much overhead
André
André Mussche: Yes, there is some overhead required to support objects. However, if those objects result in a better design the overall application may well be faster. For example, a virtual function call is much faster than repeatedly testing an if else if ladder.
Billy ONeal
@Andre, in an "equivalent program" (e.g. one that is reentrant), it would still be necessary to pass in a pointer to a structure containing data pertaining to that call... it just would not be automatic. Consider, for example, the calls in the pthread library... you still need to pass in a "pthread_t" object, it is simply explicit, so I think your statement is inaccurate. If you use shared state, then it is no longer equivalent (unless, in the OOP version, you used a static function, but then you wouldn't have the "this" pointer).
Michael Aaron Safyan
A: 

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

AKN
"obviously"? please elaborate...
Jeroen Pluimers
Sorry for being obvious. Edited my answer
AKN
+1  A: 

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.

Clifford
+1  A: 

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.

DR
object oriented CODE is slower than procedural code because of the extra (but small) overhead of object inheritance, function overiding, etc
André
+4  A: 

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

Carl Smotricz
@Carl, thanks for the plaudits... I think, though, that your statement regarding assembly language is incorrect; with the exception of assembly language optimizing gurus, assembly code generated by the compiler is almost always faster than assembly code written by hand.
Michael Aaron Safyan
@Michael: Yep, I think we basically agree. That's what my "given very skilled programmers" was about.
Carl Smotricz
+3  A: 

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.

Bruce McGee
A: 

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.

Vulcan Eager
A: 

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.

Mike Dunlavey
A: 

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

Omair Iqbal
Programs compiled with Delphi 2010 are likely to be faster then programs compiled with Delphi 7. The memorymanager has changed since then and Delphi 2010 produces better optimized code (was FastCode code used?). About bloated libraries: Big libraries may take a tiny bit more time to load, but execution speed is mainly affected by implementation (used algorithms) and probably 'feature richness'. So if library A is faster than B, A is better coded or contains less features than B, but that hasn't anything to do with OO vs procedural.
The_Fox
how can 'feature richness' make a library slow?i dont understand please clarify
Omair Iqbal
Take a look at TList implementation. In the old times (pre Delphi 5) when you cleared a TList, it just sets it's internal counter to zero and freed the memory allocated for the pointerlist. With the arrival of TObjectList, which is derived from TList, it became necessary to be notified every time an item got deleted. So when you clear a TList now, it will call Delete for every item in the list, which in turns call Notify. Clearing a TList is now an O(n) operation which was an O(1) operation before. So to implement the feature of TObjectList owning objects, another method became slower.
The_Fox