The typical C++ application will easily run 10% slower than a similar C program but that has more to do with contructing and destructing objects, passing these objects by value, exception handling, and so on. Similar conditions will exist in C applications but you leverage those facilities in a much more geneneral way in C++. Java extends that overhead with security features, garbage collection, et cetera. As you can well imagine, translating bytecode into opcode is lightening fast and you only have to do that once per class! Not only that, but you can JIT the code and cache the results. In some circumstances, not always, you can compile the whole enchilada and run your Java application as native code on whatever machine you happen to have! So they are just getting started on meaningful, elegant and transparent Java optimizations. COM overhead is extremely expensive, even for inproc, and that has a lot to do with the latest crop of Microsoft applications bogging down Pentium 200 machines with 200 megabytes of memory. Reason: take a look at how complex the delgation model is then add to that runtime type checking of VARIANT data types. That's why I claim you should use COM only when you need runtime discovery and object binding. Right now, people use it because Visual Basic needs it. That's not a good reason if you aren't using VB, IMO. Note that I do use COM and I am glad they have something like that.
BTW, one last thing on the virtual call: think of what percentage that extra level of indirection during entry is relative to the overall execution time of a typical function. It's really not much of a performance drag at all. |
