🚀 go-pugleaf

In article <1992Dec25.180242.18863@cc.umontreal.ca> soubyran@ERE.UMontreal.CA
(Soubyran Richard) writes:
>
>Hello!
>
>We are December 25th... and here I am on my computer... forgetting
>about wife and kids... but I think it is important for me!!!

Well, I guess I shouldn't comment on that, but in my own defense it IS after
Christmas here now.

>I have read in the THINK Pascal oop Manual (page 24) that oop is
>not really suited for highly algorithmic applications... It is not
>suited for computational programs... Is there anyone that could
>post performance tests comparing oop pascal and procedural pascal
>for a (moderated) highly computational program? What about C
>compared to Pascal? What about oop C compared to oop Pascal?


Such a benchmark, like most benchmarks (unfortunately) would be almost
meaningless.  The design of the program would make the difference, and
in Think's compilers the only thing that makes a program OO is whether or
not you use objects, hence there's no way to compile the same program
"object oriented" and "not object oriented".  Nevertheless, I can probably
explain why the THINK languages (and most OOP languages) are not good
at highly computational tasks:

method calls.

That's it.  Virtually all OOP languages implement message passing/method
calls as function calls.  On most systems, function calls are very expensive
relative to purely mathematical operations.

This is actually true in "pure" pascal or C as well; a program which 
multiplies two numbers N times will almost always be faster than a program
which calls a function N times, and does one multiply per function call.  
Although the same amount of "computation" is being done, the computer needs
to spend more time handling the function calls.  The difference might be
quite significant.

Message passing makes the problem worse, but only slightly, in that virtual
(overridable) methods also must execute some code or store some value that
indicates which class's method should be called (remember, the method
could be overridden in a subclass or inherited from a superclass).  This is
often quoted as a reason why object oriented systems are slow, but there's
not much to that argument -- it turns out there are some well-known methods
to make the "which method do I call" problem quite easy, but it does have
some effect.

The major reason, though, that you'll take a performance hit is that "proper"
OOP design tends to make MORE method (and hence function) calls than the
non-OOP algorithm to perform an equivalent task.  You could have your
think Pascal object just execute a for loop and do some task repeatedly,
without making any method calls, and I would argue (without proof) that 
it would be EXACTLY as fast as a non-object procedure doing the same tasks,
but then you're not really doing OOP.

However, I think that this is one of the best features of THINKA Pascal/C.
You can use Objects for tasks that objects are good at, and simple
procedure and functions for tasks that procedures and functions are good at.
The purists might not appreciate it, but in my own experience I find that
using a full class library makes my applications huge memory hogs that run
at a snail's pace.  I use small class sets for things I might want to use
again, and to create graphical "objects" on the screen that I might want to
override attributes of, but my underlying code is mostly "straight"Pascal or
C.

>I thank you all in advance for the answers and I wish you ALL a
>Merry XMas and a great new Year with alll the best you want!
>
>Richard Soubyran
>soubyran@alize.ere.umontreal.ca


Indeed, happy non-denominational winter solstice festivity period, folks.

	-Chris


------ Internet Message Header Follows ------
Path: wupost!uwm.edu!rutgers!flop.ENGR.ORST.EDU!mist.CS.ORST.EDU!kempkec
From: kempkec@mist.CS.ORST.EDU (Christopher Kempke)
Newsgroups: comp.sys.mac.oop.misc
Subject: Re: Performance tests...
Message-ID: <1hhhlrINN4h8@flop.ENGR.ORST.EDU>
Date: 26 Dec 92 12:03:07 GMT
References: <1992Dec25.180242.18863@cc.umontreal.ca>
Organization: Oregon State University, Computer Science Dept.
Lines: 76
NNTP-Posting-Host: mist.cs.orst.edu