NJ_GOKEM%FANDM.BITNET@pucc.princeton.edu (01/28/91)
Hi out there, I am taking a seminar in Object Oriented Programming, and now the class seems to believe that OOP is slower than Procedure-programming. An article in Byte in 86 argues that it could be 50 % slower. I want to help this belief out of the world! Does anyone have any comments? Or is C++, and Smalltalk slower than regular C ??? The basic argument is that the computer would spend too much time trying to find the right "METHOD" in the tree of inherited "METHODS", since OBJECTS inherit a lot of "METHODS". Is this TRUE? I will make some kind of summary, and send it to the net. Unfortunately I can only get COMP.SYS.AMIGA (thru a bitnet gateway) Nils Gokemeijer (NJ_GOKEMEIJE@FANDM.bitnet) FOOBAR: Fu%!ed Up Beyond All Reality.
tll@nntp-server.caltech.edu (Tal Lewis Lancaster) (01/29/91)
NJ_GOKEM%FANDM.BITNET@pucc.princeton.edu writes: >I am taking a seminar in Object Oriented Programming, and now the class >seems to believe that OOP is slower than Procedure-programming. >An article in Byte in 86 argues that it could be 50 % slower. I presume you are talking about execution time of the final product and not the development time of the product. >I want to help this belief out of the world! > Does anyone have any comments? >Or is C++, and Smalltalk slower than regular C ??? Yes, in most cases object oriented programs will be slower than C. One reason is they have higher overhead. That is to say they have a tendency to produce ineffiecent code. The arguments for C vs assembler speed and eiffiecency come to mind. Now most decent C compilers do a good job generating small and compact code. In most cases the performance gained by writing code in assmbler is no longer a concern (needed). >The basic argument is that the computer would spend too much time trying to >find the right "METHOD" in the tree of inherited "METHODS", since OBJECTS >inherit a lot of "METHODS". Is this TRUE? This was true for most OO languages. I don't know about now, except for Eiffel. Its scheme of dealing with "METHODS" has always been constant. It doesn't matter if there are 5 "METHODS" or several thousand. >I will make some kind of summary, and send it to the net. >Unfortunately I can only get COMP.SYS.AMIGA (thru a bitnet gateway) >Nils Gokemeijer >(NJ_GOKEMEIJE@FANDM.bitnet) >FOOBAR: Fu%!ed Up Beyond All Reality. Tal Lancaster tll@tybalt.caltech.edu
dave@cs.arizona.edu (Dave P. Schaumann) (01/29/91)
In article <42954@nigel.ee.udel.edu> NJ_GOKEM%FANDM.BITNET@pucc.princeton.edu writes: |Hi out there, | |I am taking a seminar in Object Oriented Programming, and now the class |seems to believe that OOP is slower than Procedure-programming. |An article in Byte in 86 argues that it could be 50 % slower. | |I want to help this belief out of the world! | Does anyone have any comments? |Or is C++, and Smalltalk slower than regular C ??? Yes, it is true. Object oriented programming languages are generally slower than more traditional languages. Additionally, many OOPL (like Smalltalk) are traditionally interpreted (slowing them down more). |The basic argument is that the computer would spend too much time trying to |find the right "METHOD" in the tree of inherited "METHODS", since OBJECTS |inherit a lot of "METHODS". Is this TRUE? The designers of C++ took the course of getting OO functionality with the minimum amound of cost at execution time. They got it down to the cost of an extra indirection for every function call. Eg., a call like bar->foo() in C++ translates to something like (*bar->foo)() in actuality. (modulo the hidden 'self' parameter, of course). The moral of the story is There Aint No Such Thing As A Free Lunch. (say, that sounds familiar...) |Nils Gokemeijer |(NJ_GOKEMEIJE@FANDM.bitnet) Dave Schaumann | And then -- what then? Then, future... dave@cs.arizona.edu | -Weather Report
tsarna@polar.bowdoin.edu (Tyler Sarna) (01/30/91)
In article <42954@nigel.ee.udel.edu> of comp.sys.amiga.misc, NJ_GOKEM%FANDM.BITNET@pucc.princeton.edu writes: > I am taking a seminar in Object Oriented Programming, and now the class > seems to believe that OOP is slower than Procedure-programming. > An article in Byte in 86 argues that it could be 50 % slower. > I want to help this belief out of the world! > Does anyone have any comments? > Or is C++, and Smalltalk slower than regular C ??? Smalltalk is slower because it is interpreted. > The basic argument is that the computer would spend too much time trying to > find the right "METHOD" in the tree of inherited "METHODS", since OBJECTS > inherit a lot of "METHODS". Is this TRUE? C++, as a compiled OOP language, finds the right method at compile time, unless a method is declared "virtual". ------///------------------------------------------------------------ /// Tyler "Ty" Sarna E-Mail: tsarna@polar.bowdoin.edu \\\/// "The Electric Monk was a labour-saving device..." --\XX/---------------------------------------------------------------
new@ee.udel.edu (Darren New) (01/30/91)
>|I am taking a seminar in Object Oriented Programming, and now the class >|seems to believe that OOP is slower than Procedure-programming. >|An article in Byte in 86 argues that it could be 50 % slower. >Yes, it is true. Object oriented programming languages are generally slower >than more traditional languages. Additionally, many OOPL (like Smalltalk) >are traditionally interpreted (slowing them down more). Actually, many good analysies (sp?) are available in ACM SIGPLAN OOPSLA proceedings. Objective-C, last I heard, had the average overhead for a method call (dynamically bound) down to 1.25 the cost of a function call. Many great optimizations are possible. I seriously doubt any commercial OOP systems run at 50% the speed of non-OOP systems. If you want to see what is *really* going on, I can't recommend OOPSLA enough. There has been great progress over the last few years. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- =+=+=+ Let GROPE be an N-tuple where ... +=+=+=
estdwha@warwick.ac.uk (CrisP) (01/30/91)
In article <749@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: >In article <42954@nigel.ee.udel.edu> NJ_GOKEM%FANDM.BITNET@pucc.princeton.edu writes: >|Hi out there, >| >|I am taking a seminar in Object Oriented Programming, and now the class >|seems to believe that OOP is slower than Procedure-programming. >|An article in Byte in 86 argues that it could be 50 % slower. >| >|I want to help this belief out of the world! >| Does anyone have any comments? >|Or is C++, and Smalltalk slower than regular C ??? > >Yes, it is true. Object oriented programming languages are generally slower >than more traditional languages. Additionally, many OOPL (like Smalltalk) >are traditionally interpreted (slowing them down more). > >|The basic argument is that the computer would spend too much time trying to >|find the right "METHOD" in the tree of inherited "METHODS", since OBJECTS >|inherit a lot of "METHODS". Is this TRUE? > >The designers of C++ took the course of getting OO functionality with the >minimum amound of cost at execution time. They got it down to the cost >of an extra indirection for every function call. Eg., a call like >bar->foo() in C++ translates to something like (*bar->foo)() in actuality. >(modulo the hidden 'self' parameter, of course). Not quite. bar->foo() in C++ translates to something like foo(bar) in C. Actualy it doesn't use foo but a symbol that is "unique" to a call the foo in that perticular class. ( Whatever class bar may be. ) So in theory a C++ program should execute just as fast as a C program. The style of object oriented programming sacrifices some executing speed for development speed. In reality the C++ compilers arn't as good as the C compilers alough there is no reson why the can't be. I don't know how the C++ to C interpreters produce less efficent code than code written C in an similar style, but CC-2.1 on a Sun3 seems to do it. > >The moral of the story is There Aint No Such Thing As A Free Lunch. >(say, that sounds familiar...) > >|Nils Gokemeijer >|(NJ_GOKEMEIJE@FANDM.bitnet) > > >Dave Schaumann | And then -- what then? Then, future... >dave@cs.arizona.edu | -Weather Report ~CrisP. -- ------------------------------------------------- crisp@uk.ac.warwick.cs | estdwha@uk.ac.warwick.cu -------------------------------------------------