Author: Matt Taylor
Date: 00:03:46 02/14/03
Go up one level in this thread
On February 14, 2003 at 01:46:12, Dann Corbit wrote: >On February 14, 2003 at 01:03:03, Matt Taylor wrote: > >>On February 14, 2003 at 00:07:50, Matthew Hull wrote: >> >>>On February 13, 2003 at 23:21:57, Dann Corbit wrote: >>> >>>>Deep Junior is OOP >>> >>>If so then it is interesting. I don't program OOP myself, so I was pretty much >>>quoting the promise of OOP from a buisness perspective in which utility and >>>economy of human resources were the selling points rather than performance. >>> >>>Matt >> >>I debated performance a while back (a month or two ago I think) here with some >>of the others. Object oriented code isn't necessarily that bad. (Java gives it a >>bad rep because Java has notoriously bad performance.) > >Java is interpreted on the fly or JIT compiled. Hence, it cannot be as >efficient. There are native Java compilers, but they still have to deal with >GC, even at that. Even with all that, the performance penalty for Java is only >2x-4x. Some claim even less. Yes, on good JVMs. Sun's is awful. A good friend of mine recently informed me of a leaked Sun memo documenting programs that consumed 900+ MB of ram. A Hello World program took 20 MB. I don't know which version of the JVM or what the first program was doing; all I know is that the memo documented opinion that the Sun JVM is not terribly great. I have a 486 33 MHz sitting on my desk at home. About the only purpose it has now is to make the room a little brighter at night. It has Sun's JDK installed, but I would never dare compile anything on it. Sun's Java compiler is written in Java, and I have to wait minutes for an answer, even on a small file. Conversely, gcc will spit out an answer very quickly. As a language, Java should be as efficient as C or C++ or any other language. Unless the application is poorly written, GC really shouldn't impact performance as much as memory footprint. Memory allocation is -always- slow, and many programmers use new and delete more than any other operator. Hmm. The class library might hurt it, but I can't see offhand why Java's class library would be any worse than C's or C++'s. >>Another consideration is that you can write object oriented stuff in any >>language -- even assembly if you really want to. I write object-oriented >>libraries in C all the time. I find it distasteful to mix distinct segments of >>the library together unless absolutely necessary. > >I have seen OO assembly and Cobol and C++ spaghetti. > >Where I work (CONNX Solutions Inc.) all the programming is C++ OO stuff. We >write low level database drivers in C++. We outperform every competing product. > >My position is that there is very, very little performance penalty for OOP, and >that the increase in apparent simplicity (actually, the complexity is merely >hidden) helps to write more efficient code. The simplification in the model by >better abstraction more than pays for itself in the long run. Writing better >algorithms is dominatingly more important than writing tweaky little >improvements. Of course. If you find yourself unable to find a better algorithm, though... Data hiding is still nice. Practically I don't think it makes a huge performance difference to hide internals through an abstraction layer, particularly if you can use inline assembly. Supposedly VC 7 pushes inline assembly decisions into the linker. All I have to say is it's about time. -Matt
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.