Yup, Java was developed by Sun Microsystems in the early 90''s. It''s original objective was to create a system to comunicate to different house-hold appliances. When that failed it was used as a completely system independent programming language ( the reason you need a JVM ).

there''s some real good information at the begining of this one book, core java fundamentals. i think it''s written by sun. it has some good information on the background of java and how it''s compiled and why it''s slower. just read the first chapter in a bookstore or something

There's no significant speed difference between C and C++ anymore. C++ used to be poorly compiled due to being converted to C and then compiled with standard C compilers. Modern optimizing C++ compilers do not do this and do a really good job at optimizing C++.

Of course, C++ in practice can be a bit less efficient than C. This is not due to any problem with C++, its due to abstraction allowed by object oriented design. When setting a variable in a C++ class, for example, you might call methods like SetVariable(), whereas in C you would just set the variable directly in your main code flow. This is a conscious design decision on the C++ programmer's part to abstract the underlying data from the class interface, and it is usually worth it because it results in code that is easier to maintain and understand in large projects.
A good C++ programmer will determine when these little bits of overhead are worth it and when they are not, and will use tools such as inline functions to construct code that is essentially just as fast as the same algorithm in C.

C++ function calls aren't slower by default than C function calls (something the original poster asked about). There is an exception to this: C++ virtual functions (used to allow sane polymorphism in base classes) are ever so slightly less efficient during the function call setup because it has to call into the function through a table, its not a direct function binding. Again, a good C++ programmer will be able to decide when virtual functions are worth it for the ease of clean design they offer and when they are not (tight loops, etc).

As far as Java goes, Java can be quite fast, as others have mentioned. You can actually compile Java direct to machine code using some tools such as GCJ. In doing so you often lose some of the nice features of Java, such as reflection, but as always a good programmer has to weigh the pros and cons of each design and implementation detail: is it worth it? It depends.

There are other Java technologies like Hotspot that allow you to use the full Java language and optimize code at runtime. As others have mentioned these can make the code very fast, but these are generally more useful for long running (usually server side) programs. A client program needs to be responsive right away, not 5 hours after it starts running. This has really been the sticking point of Java. Despite Sun's past claims of C++-like execution, a GUI-based Java program using Swing is generally noticably slower than a similar C++ program on the same hardware. In its defense, Sun has been doing a lot to address the speed issues, and there are some features in Java 1.4 that should help out even more, but as of right now they still exist and can be a problem depending upon the size and complexity of the Java program you want to distribute.

Another potential drawback of Java is that deploying Java applications can be more complex than usual as you need to make sure the user has an appropriate JVM installed on his/her system. You can include a JVM installer within your app's installer but that will generally balloon the size of your application by several megabytes. Not a problem for CD distribution, but can be a problem for net distribution.


Edited by - gmcbay on August 3, 2001 2:09:40 PM

Any C++ method will be slightly slower than a C function, because there is an extra stack push to pass what instance of the object you''re calling from. This is basically negligible with today''s PCs, but I remember people were concerned about it when C++ was first introduced (myself included. Heh.) Of course, at the time people would nitpick just about anything about object oriented programming. Structured coding (killing the goto) had the same initial negative reaction.

Java''s slowness is often attributed to bytecode, but that isn''t really true. You can get java compilers that compile to native code, and it still runs slower than C++. This is because Java includes features that C++ does not, such as run time array bounds checking and garbage collection. More features takes more time.

quote:Original post by CheeseGrater
Any C++ method will be slightly slower than a C function, because there is an extra stack push to pass what instance of the object you''re calling from.

No! This is a common misconception. Firstly, being pedantic, the ''extra'' parameter rarely goes on the stack. For example, in Visual C++, I believe it is passed in the EBX register. Secondly, and mainly, all you''re doing is passing a pointer to the class. To do the same thing in C, you would have to pass a pointer to the struct anyway.

C++ call: MyObject->SomeFunction(Param1, Param2);C   call: SomeFunction(MyObject, Param1, Param2); 

The only difference is that for the C++ version, one of the parameters (the pointer to MyObject) is ''hidden'' because it''s not an explicit parameter. This is an example of how C++ has ''hidden'' overhead... however, in total, it still adds up to exactly the same amount of data being passed.

I recognize that passing in a structure causes an equal performance hit. When we used to voice that concern, what we were really complaining about was that encapsulation would cause additional overhead _when you only had one instance_.

When there''s one instance, there''s no extra information to pass, so you can globalize it and remove what was at the time a stack push/pop, and is now just a register move.

Gosh, I haven''t even thought of this junk in years. We cared about this when we were programming for Xwindows on 20Mhz MIPS processors (Heh. My first Xwindows 3D rendering program ran at 0.1 FPS). The function overhead basically makes no difference on today''s monster P4''s. But hey, thy guy wanted history. Maybe the fact that programmers initially resisted C++ for reasons like that will make a nice footnote.