Thread: Speed of C++

>> You sure can see past the apparent sttrictness of my previous post.
I felt that your exaggeration was misleading and offered my take on the subject. "Arrays are evil" statements are fine, IMO, because in 99% of cases that is true and in many cases the beginner doesn't realize that the number is that high. However, identifying which solution is more appropriate for a given problem is perfectly acceptable, and hyperbolic statements implying that speed never matters in such a discussion are just wrong. Speed does matter and should be taken into consideration even if the final resolution is that the speed difference is negligible.

Originally Posted by Daved

>> You sure can see past the apparent sttrictness of my previous post.
I felt that your exaggeration was misleading and offered my take on the subject. "Arrays are evil" statements are fine, IMO, because in 99% of cases that is true and in many cases the beginner doesn't realize that the number is that high. However, identifying which solution is more appropriate for a given problem is perfectly acceptable, and hyperbolic statements implying that speed never matters in such a discussion are just wrong. Speed does matter and should be taken into consideration even if the final resolution is that the speed difference is negligible.

Well, I suspect Mario's tongue was firmly in cheek when he wrote his post. But his basic message is right: people tend to focus much more on speed/performance of an application than is really necessary.

That is true of developers, hence the phenomenon of premature optimisation. That causes problems because it often turns out that premature optimisations often, in the long run, do not optimise performance at all because a compiler (which is designed with knowledge of the target machine) can often do it better than a human -- and also because, in worst cases, some premature optimisers sacrifice correctness to achieve speed and that causes a future maintenance nightmare. Professionals will focus on getting the application running correctly and then, with the help of tools like profilers, find the hot spots in an application. In other words, the performance optimisation is performed late in the development cycle, not early.

End users will focus on speed/performance when they don't need to. And, by doing so, they sacrifice their own productivity. With a word processor, for example, the speed of a particular operation rarely matters as much as the higher level features offered by the tool (eg being able to reduce errors due to typos, misspelling, grammar, incorrect referencing, ability to do backups, etc etc). But users will tend to complain about things like slow startup, speed of saving a file to disk, etc etc. Performance of such things CAN be important, but users emphasise them much more in problem reports than is necessary -- they are functions for which correctness is more important than speed. In worst cases, in some problem domains, I've encountered end users who insist on "real time performance" (by which they mean things like "instantaneous response to a GUI", not the real technical meaning) and, when given a choice between correctness and performance, will always choose performance. Despite formal analysis in those domains, in some cases, which shows that correctness is necessary for mission success, human safety, etc. My basic message is that, even when users focus on performance, the developer is doing them a disservice by catering to them.

In the (relatively rare) cases where performance is really important, it is skill of the developer that is most important. In practice, C++ will often be faster than Java, simply because it doesn't have overheads such as a virtual machine and the compiler has more opportunities to optimise for performance by getting closer to the target machine. There are also performance issues as the Java library is not as heavily optimised as the standard C++ or C libraries that are associated with most good quality compilers. The "safety" in Java usually comes at a cost -- and one of those costs is usually performance. On the other hand, in some areas, a Java application will be faster than a C++ application because Java is optimised for some types of application that C++ isn't. Consider things like distributed component frameworks (aka Beans) and it often turns out that a suite of applications written in Java will, collectively, outperform a comparable suite of similar applications written in C++ because the Java frameworks are better optimised for distributed work and more directly accessible to the developer (the balance, however, is pulled back to C++ by use of good-quality libraries, such as CORBA ORBs, written in C++). Run time techniques in Java (eg JIT) can also result in performance gains for certain types of Java applications in comparison with C++.

But, in the wider world, choice of language is not that important. I would bet in favour of a skilled developer, in either language, over an unskilled developer in the other language --- any day. Both in terms of achieving performance by squeezing the most from the tools (should that be required) and correctness.