Re: Making Guile slower (3.4 and 6.7%). (was Re: NIMP thing)

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Greg Harvey <Greg.Harvey@thezone.net> writes:

> Yeah, but I didn't think it warrented the discussion time in the
> beginning,

So, why are you continuing to discuss?

I'm discussing because I think the ideas I'm trying to convey are
important in general, and because I don't think the arguments which
I'm countered with are valid.  Also, they are pretty twisting.  If I'm
right about stability, then I'm wrong about efficiency.  But if I'm
right about efficiency, then I'm wrong to spend time discussing it.
If I'm right about basing changes on solid knowledge about the
effects, then I have a different perspective on the tradeoff between
code reusability, maintainability, evolvability vs. performance.

I try to stop this discussion all the time, but are being met with
arguments which I simply can't resist responding to.

> Yes, maybe we should profile every single change that goes in (did
> the addition of goops support to the evaluator slow it down?

Most pieces of Guile are not time critical, but the evaluator is.  We
don't need to benchmark at most changes, but we should benchmark at
_every_ change that is expected to influence general performance.

The argument is that this is a "slippery slope", that is, since we are
not likely to accidentally make a change which speeds up the
evaluator, every change influencing performance will systematically
make it worse.  5% is not much, but after a few such changes, Guile
will be substantially slower.

I have already said this in other words, but obviously failed
conveying the underlying idea, so I have to keep discussing.  If these
issues doesn't get attention enough, we _will_ get a substantially
slower Guile, and we _will_ get a Guile beginning to segfault.

Concerning GOOPS, those changes were made in the most conservative way
possible.  The major change in the evaluator with chance of effecting
performance was adding a few new entries in a switch.  This shouldn't
cause much change in performance but could of course influence cache
behaviour and could convert short branch instructions to long branch.

The GOOPS change was the most conservative change possible, but the
NIMP change isn't.

> (given that there are so many other ways you could improve the
> performance of guile a lot more than counting instructions in the
> evaluator).

Interesting.  I hope you'll implement these ideas.  Most changes I can
think of are pretty tricky to implement, and are in fact changes to
the evaluator (like incorporating the environment cache of SCM).