dsr@stl.stc.co.uk (David Riches) (04/17/89)
I'm putting this on the net for a friend, hence the two signatures. Can anyone who replies directly send mail to both of us, else a posting will be fine. I'm using C++ in the VLSI routing domain, where software has previously been written in a number of languages. Not much in OOLs however ( as far as I am aware ). Speed is a very important factor when considering the advantages and disadvantages of routing algorithms, and as a result I am interested in the overhead due to messaging in OOP when compared to "conventional" programming. Does this overhead affect the speed of my software in any significant way? I would appreciate any comments from anyone knowledgable in this subject matter or even some references on messaging overhead in OOP. --sanjiv Sanjiv Gossain | goss%ese.essex.ac.uk@nss.cs.ucl.ac.uk Dept. of ESE | Tel: +44 206 873333 Ext. 2820 University Of Essex Colchester CO4 3SQ ENGLAND ------------------- from, Dave Riches PSS: dsr@stl.stc.co.uk ARPA: dsr%stl.stc.co.uk@earn-relay.ac.uk Smail: Software Design Centre, STC Technology Ltd., London Road, Harlow, Essex. CM17 9NA. England Phone: +44 (0)279-29531 x2496
mikpa@majestix.ida.liu.se (Mikael Patel) (04/18/89)
Hi, the answer is NO. Typically the application you are doing the time complexity of the overall algorithm is the major problem. C++ gives you inline procedure expansion (when possible) and virtual procedure very cheap (approx. an indirect subroutine call). Your real problem is graph representation to reduce time complexity.
ark@alice.UUCP (Andrew Koenig) (04/19/89)
In article <1357@stl.stc.co.uk>, dsr@stl.stc.co.uk (David Riches) writes: > Speed is a very important factor when considering > the advantages and disadvantages of routing algorithms, > and as a result I am interested in the overhead due to > messaging in OOP when compared to "conventional" programming. C++ does `messaging' by calling virtual functions. Calling a virtual function in C++ is only a little slower than calling an ordinary member function. How much slower depends, of course, on your machine and C compiler. To get some specific evidence, I tried it on my home machine (a MicroVAX II): struct Foo { void f(); virtual void g(); }; main() { register Foo* fp; fp->f(); fp->g(); } The code generated for fp->f() looks like this: pushl r11 calls $1,<Foo::f> and the code for fp->g() looks like this: movl (r11),r0 cvtwl 8(r0),r0 addl3 r0,r11,-(sp) movl (r11),r0 calls $1,*12(r0) So the virtual function call takes three extra instructions and three extra memory references. On this particular machine, a subroutine call/return instruction pair take a lot longer than three memory references, so the extra cost for a virtual function call is insignificant. The overhead would be relatively greater on a machine with extremely fast call/return instructions, but is still small in absolute terms. -- --Andrew Koenig ark@europa.att.com
jima@hplsla.HP.COM (Jim Adcock) (04/21/89)
> C++ does `messaging' by calling virtual functions. > Calling a virtual function in C++ is only a little > slower than calling an ordinary member function. Hm, I guess I'd like to argue a little this definition of "messaging" as applied to C++. I'd like to claim that whenever I use a construct similar to: myObject.aMessage(withParams); -- or -- myObjectP->aMessage(withParams); -- then I've sent a message to an object in C++, regardless of the code that actually gets generated to perform this task. [Why should I, the class user, care how the class writer, or the compiler conspire to make this message happen -- as long as its damned fast!?] C++ gives the writer of the class that myObject belongs to several choices on how the request for a message to be sent to an object gets turned into code to do the job. Depending on what needs to be done, the "messaging" request may compile into: X times faster an indirect function call 10-100 a function call 5-50 inline code [example: a simple assignment] 100-1000 nothing infinitely -- where the "X times faster" column is intended to give a rough feel of the decimal order of magnitude times faster C++ is for this coding of a "message" verses what might be expected from other OOP languages that use hashed look-up schemes. Perhaps, most importantly are C++'s advantages in the last two cases. Frequently in OOP a message request simply sets or returns a simple value from inside an object: [myComplexNumber imagPart: 0.0]; or double imag = [myComplexNumber imagPart]; Using inline functions in C++, these simple "assignment"-type methods which are so common in OOP get turned into the same code as for C simple assignments: myComplexNumber.im = 0.0; or double imag = myComplexNumber.im; Finally, a good optimizing back end code generator may well discover that the inline code that is generated serves no useful purpose, and so removes it. Thus sometimes, no code whatsoever need be generated in the implementation of a C++ messaging request. Clearly, you cannot expect these levels of optimization in other OOPLs.