[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Mikael Djurfeldt
Subject: Re: guile/guile-core/libguile eval.c
Date: 27 Feb 2001 04:10:33 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]