Re: OOP overhead (Was: tiny contest...)

Chris Gehlker <[e-mail]> writes:

> While I agree with the thrust of Sean's comment, I have to quibble with a
> detail. The degree of overhead that one pays for OO is very language
> dependent. If we can agree for sake of argument that C++ is an OO language,
> despite what Alan Kay said, then the cost of a method call is one extra
> address lookup and the cost of object creation is not that much higher than
> initializing a struct. In ObjC the first time you call a method it's
> expensive but thereafter the address is cached and it's fairly cheap.

Agreed, but in this particular case, the code is changing from (say)

   wordlist.each do |word|
     hashed_word = hash_of(word)
     anagrams[hashed_word] = word
  end

to

   def String.hash
      hash_of(word)
   end

   wordlist.each do |word|
     anagrams[word.hash] = word
   end

which effectively doubles the number of method calls (because hash_of
is a method call itself.

However, I don't think this is an indictment of OO either. When you
design OO structures, you have to make the same tradeoffs that you
make with procedural ones in order to get performance. Sometimes this
means breaking encapsulation in order to cache data, or break long
method chains. The trick then is to encapsulate the damage (in the
example above, this might involve making the wordlist an class which
hides the hashing business from the outside world). I suspect I could
re-structure the addagram solution this way with no more than a 10-15%
penalty.

However, that then raises the interesting question.

Why?

In this case, is there a benefit to an OO solution? Perhaps there is,
perhaps there isn't. But I don't think that it's a slam dunk.


Dave