On Wed, 10 Oct 2001, Eddie Cottongim wrote:

>
> "Simple speed test which may or may not characterize average case usage:"
> m := EllipseMorph new.
> Time millisecondsToRun: [ 100000 timesRepeat: [m isHandMorph] ] 60 ms
> Time millisecondsToRun: [ 100000 timesRepeat: [m isKindOf: HandMorph] ] 351
> ms

First, this isn't good benchmarking. isKindOf is fairly assymetric, in
that it can be a lot more expensive when the result is false then when it
is true. Thus, any cache needs to cache negative results too.

But, I'd not be concerned about this performance at all. This is still
300,000 isKindOf's per second. I doubt any code is going to use it this
much, but, if profiling does find code that does use it enough that this
is consuming CPU time, the correct fix isn't to create a strange
workaround, but rather to speed up this operation. Make an isKindOf:
lookup cache, or do the work in a primitive. (Use a bytecode and a cache
and I think you can make isKindOf faster than a method invocation.)

IE, I wouldn't worry one whit about it being slower; if necessary, this
change might make 'isKindOf:' faster than 'isHandMorph'. If you're making
isXYZ methods for speed reasons, don't.

BTW, why do the isXYZ functions exist? Why not use isKindOf. They both do
the same thing, but one creates a lot of extra methods in Object, and
other big base clases that already have too many methods.

Other people have said that isKindOf is 'bad style', but is isHandMorph
any better? They both do the same thing and both solve the same sort of
problem, basically, multimethods.

(Multimethods are when you wish to do dynamic dispach based on more than
one argument to a function. For example:
  Foo, Bar are subclasses of Collection
   Foo>>quickAppend: aBar.
   Foo>>quickAppend: aFoo.
   Bar>>quickAppend: aFoo.
   Bar>>quickAppend: aBar.)

Andreas, you said that you'd heard it was bad design and bad style. Why?

> I've always stuck with isKindOf in my work beacuse I thought it was the
> "right thing" to do. I'm guessing that the testing methods in Object, Morph
> etc are there for speed reasons. So, as a programmer, I should start with
> isKindOf and create explicit methods if isKindOf is a speed bottlenect. Am I
> missing any other considerations ?


IMO, continue to do the right thing, only worry about speed of isKindOf if
and only if profiling does show it to be a problem. And even if, at some
future point isKindOf does become a problem, implement one of the
speedups.

BTW, this also applies to respondsTo:, that can make that fairly cheap in
exactly this fashion.

If performance considerations are why we don't use respondsTo: or
isKindOf:, next month I can work on a a cache, and a slang plugin to
automate it.


Scott



--
No DVD movie will ever enter the public domain, nor will any CD. The last CD
and the last DVD will have moldered away decades before they leave copyright.
This is not encouraging the creation of knowledge in the public domain.