🚀 go-pugleaf

RPG writes:

> I think this concern over dispatch time is insane. It might have made
> sense 20 years ago (that is, when C was invented) when computers were
> < .1 mips and cost more than 5 years of a hacker's salary, but not
> today when computers are > 20 mips and cost 1/5 of a hacker's salary.

I partially agree with this.  I think it would be a mistake to
add a bunch of kludgy mechanisms to the language just to speed
up dispatch time, for instance.

On the other hand, I don't think the implementors who have put
a great deal of effort into speeding up method dispatch have been
wasting their time, and I don't think it doesn't matter how much
slower CLOS is than C++ or how much slower generic functions are
than ordinary ones.

If the difference is only 10-20%, then it's not a problem; but
if we're talking small integer factors, that's a different story.
We have some programs here that take, say, 8 hours to process a
"realistic" example.  It would make a big difference to cut it
to 4.  Sure, we could wait for the next "mini-generation" of
machines (which, if recent trends continue, will be about twice
as fast) and cut it to 4 hours that way.  But if we can do that,
it would be even better to have a faster program and a faster
machine and run it in 2 hours.

It also turns out that when we use CLOS we might have to justify
this choice to customers.  It will be a lot easier to do this if
the time cost isn't very great.

Of course, method dispatch might acount for only a small faction of
the total time.  But, in other cases, it's more.  In order to tell
when it's "safe" to use generics, we need to know what cost is
involved.