Re: Making Guile slower?

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

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

[Interesting tests deleted.]

> And so on. In any case, I think it's a pointless bit of pennypinching
> to worry about one test in the vast pile of code that is guile,
> particularly if it makes it less likely to introduce bugs.

Now, firstly, I repeatedly forget that I'm not any longer a Guile
developer but a Guile user, so you clearly have more say in this than
I have.

Secondly, I've not said that it is a bad change.  I said it should be
preceded by benchmarks and discussion.  My purpose is just to sound
the alarm bell since what looks like an innocent improvement of the
Guile macros is in fact something which needs a great deal of thought
and consideration.

It's actually not one test.  It's tests spread throughout the Guile
code.  It's a fundamental change of the way you write Guile code, a
change in Guile's design.  With this change, some parts of the
evaluator should be optimized differently.  You'll instruct people
differently in the manuals, etc.

But, in reality, measuring the real effects of this type of change can
indeed be difficult because of the complex behaviour of modern CPU's.
I've seen changes in efficiency by 30% just because I moved a function
in eval.c from one place to another (well, this could actually be
explained).

Anyway, I *am* worried, until I know that it doesn't adversely affect
performance.  Intuition says that introducing such frequent extra
tests should affect performance, but it may be shadowed by other
things.  Also, I think it's important to be very careful with changes
that affect performance.  If you have a sloppy policy with this, the
gap in performance compared to SCM will increase.