home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / mac / oop / misc / 143 < prev    next >
Encoding:
Internet Message Format  |  1992-12-26  |  4.0 KB
  1. Path: sparky!uunet!spool.mu.edu!uwm.edu!rutgers!flop.ENGR.ORST.EDU!mist.CS.ORST.EDU!kempkec
  2. From: kempkec@mist.CS.ORST.EDU (Christopher Kempke)
  3. Newsgroups: comp.sys.mac.oop.misc
  4. Subject: Re: Performance tests...
  5. Message-ID: <1hhhlrINN4h8@flop.ENGR.ORST.EDU>
  6. Date: 26 Dec 92 12:03:07 GMT
  7. References: <1992Dec25.180242.18863@cc.umontreal.ca>
  8. Organization: Oregon State University, Computer Science Dept.
  9. Lines: 76
  10. NNTP-Posting-Host: mist.cs.orst.edu
  11.  
  12. In article <1992Dec25.180242.18863@cc.umontreal.ca> soubyran@ERE.UMontreal.CA (Soubyran Richard) writes:
  13. >
  14. >Hello!
  15. >
  16. >We are December 25th... and here I am on my computer... forgetting
  17. >about wife and kids... but I think it is important for me!!!
  18.  
  19. Well, I guess I shouldn't comment on that, but in my own defense it IS after
  20. Christmas here now.
  21.  
  22. >I have read in the THINK Pascal oop Manual (page 24) that oop is
  23. >not really suited for highly algorithmic applications... It is not
  24. >suited for computational programs... Is there anyone that could
  25. >post performance tests comparing oop pascal and procedural pascal
  26. >for a (moderated) highly computational program? What about C
  27. >compared to Pascal? What about oop C compared to oop Pascal?
  28.  
  29.  
  30. Such a benchmark, like most benchmarks (unfortunately) would be almost
  31. meaningless.  The design of the program would make the difference, and
  32. in Think's compilers the only thing that makes a program OO is whether or
  33. not you use objects, hence there's no way to compile the same program
  34. "object oriented" and "not object oriented".  Nevertheless, I can probably
  35. explain why the THINK languages (and most OOP languages) are not good
  36. at highly computational tasks:
  37.  
  38. method calls.
  39.  
  40. That's it.  Virtually all OOP languages implement message passing/method
  41. calls as function calls.  On most systems, function calls are very expensive
  42. relative to purely mathematical operations.
  43.  
  44. This is actually true in "pure" pascal or C as well; a program which 
  45. multiplies two numbers N times will almost always be faster than a program
  46. which calls a function N times, and does one multiply per function call.  
  47. Although the same amount of "computation" is being done, the computer needs
  48. to spend more time handling the function calls.  The difference might be
  49. quite significant.
  50.  
  51. Message passing makes the problem worse, but only slightly, in that virtual
  52. (overridable) methods also must execute some code or store some value that
  53. indicates which class's method should be called (remember, the method
  54. could be overridden in a subclass or inherited from a superclass).  This is
  55. often quoted as a reason why object oriented systems are slow, but there's
  56. not much to that argument -- it turns out there are some well-known methods
  57. to make the "which method do I call" problem quite easy, but it does have
  58. some effect.
  59.  
  60. The major reason, though, that you'll take a performance hit is that "proper"
  61. OOP design tends to make MORE method (and hence function) calls than the
  62. non-OOP algorithm to perform an equivalent task.  You could have your
  63. think Pascal object just execute a for loop and do some task repeatedly,
  64. without making any method calls, and I would argue (without proof) that 
  65. it would be EXACTLY as fast as a non-object procedure doing the same tasks,
  66. but then you're not really doing OOP.
  67.  
  68. However, I think that this is one of the best features of THINKA Pascal/C.
  69. You can use Objects for tasks that objects are good at, and simple
  70. procedure and functions for tasks that procedures and functions are good at.
  71. The purists might not appreciate it, but in my own experience I find that
  72. using a full class library makes my applications huge memory hogs that run
  73. at a snail's pace.  I use small class sets for things I might want to use
  74. again, and to create graphical "objects" on the screen that I might want to
  75. override attributes of, but my underlying code is mostly "straight"Pascal or
  76. C.
  77.  
  78. >I thank you all in advance for the answers and I wish you ALL a
  79. >Merry XMas and a great new Year with alll the best you want!
  80. >
  81. >Richard Soubyran
  82. >soubyran@alize.ere.umontreal.ca
  83.  
  84.  
  85. Indeed, happy non-denominational winter solstice festivity period, folks.
  86.  
  87.     -Chris
  88.