Re: guile/guile-core/libguile eval.c

[Mikael Djurfeldt]

Marius Vollmer <address@hidden> writes:

> Mikael Djurfeldt <address@hidden> writes:
> 
> > The main point is that it's kind of silly to have to do this kind of
> > tests in the inner loop of the evaluator.
> 
> Yes, but note that the test is only done once at the start of
> evaluating a body.  It is not done for every form of the body.  The
> updating itself is only done on top-level of course, and I think we
> don't need to worry too much about the performance there.

We have said previously that we always should do a benchmark when we
make changes to the evaluator which may affect performance, so i did
that.

The user time for benchmark (benchmarks eval2) increased by 5.9%
between Guile versions 2001-02-11 and 2001-02-12.  Total time
increased by 4.2%.

[The values were measured on an i386 333 MHz Pentium II system running
Debian 2.2 with a 2.4.1 kernel.  The guile binaries were statically
linked.  The machine was freshly booted with a minimum number of
processes running.  There was a difference in the fourth digit between
multiple runs of the tests.  (There's always an initial speedup when
the memory hasn't been exercised.  I put several runs of the two
Guiles in an alternating sequence.)]

This isn't much, and benchmarks have previously shown strange results,
but it *is* enough that I think we should factor this condition out of
the interpreter.

One possibility is to let, for example, a cond expand into

  (cond (CEXP (@top-level-begin EXP1 ...))
        ...)

when on top level.