Re: when to use generic methods as opposed to "regular" pocedures

From: Erick Gallesio <eg_at_unice.fr>
Date: Thu, 22 Oct 1998 23:38:38 +0200 (CEST)

Brian Denheyer writes:
>
> I have developed a habit of making anything which takes an argument
> which is a class a generic method. It then occured to me that a
> "regular" procedure is likely to be faster since there is no method
> look-up.
>
I suppose that what you call a "generic method" is a method.

> I then realized that this may not be true depending on how method and
> procedures are implemented, i.e. maybe "regular" procedures are
> implemented as special case generic functions and therefore there is a
> look-up cost associated with them anyways.
>
> So the question is, when should a method be used vs a regular
> procedure definition, when either can be used ? Is it really more
> expensive to use a method vs. a procedure ?
>

That's exactly the case. In fact methods are implemented using RnRS
Scheme procedures (i.e. "lambdas"). There is no lookup cost associated
to a procedure whereas there is an overhead for methods. In fact when
you call a generic function with only one associated method, you
reference the generic function. From this function, the sstem has to
pick the most specific method of the gf (in this case there is only
one) and finally verify that the parameter is in the
class-pecedence-list of the method argument.
So yes, it costs a little bit more...
Timing this sort of thing is a little bit tricky, but as far as I
remember (and quick test seems to confirm that), if there is only one
method associated to a gf, calling the gf is 2.2 times slower than
calling directly the function.

> I am probably going to start using the rule that functions which do
> not need to be "overloaded" will be implemented using a "regular"
> procedure.
>
This is a general rule that I apply. Even ifit appears later that the
function must be overloaded, this is not a great deal, since STklos
uses the procedure as a "falling case" method if no method is found:

         (define (f x)
           'base-function)

         and sometime later

         (define-method f ((x <integer>))
            'integer)

         (define-method f (x y)
            'two-parameters)

         (f 1) -> integer
         (f 1 2) -> two-parameters
         (f #f) -> base-function
       
> The only other consideration is that using methods can provide a sort
> of type checking since you'll get an error if the args don't match-up,
> but I find that this is does not accur so often that it would really
> help me that much.

This is of course an advantage, and if you need to insure inside the
function that the argument is of the given type, you probably better
use a method since the type test will be done in C rather than in Scheme.
Furthermore, the error is trapable with the no-applicable-method
method. However, I must admit that I have not tried to time this very
precisely.

                -- Erick
Received on Thu Oct 22 1998 - 23:38:10 CEST