Re: status: separation of expansion/optimization/memoization/execution

[Rob Browning]

Dirk Herrmann <address@hidden> writes:

> Basically, with the changes above everythings still works as before,
> that is, expansion and friends are still executed dynamically during
> execution.  However, the functionality of each of the
> builtin-mmacros is more cleanly separated into different tasks with
> different responsibilities.  And, I have added more exhaustive
> syntax checks into the expand_foo functions.

Eeeeexcelent :>

> The effect so far is, that booting guile takes noticably longer (at least
> 15%), but for example executing the test-suite is almost as fast as before
> (2% slower).  Unfortunately, it is not yet possible to achieve large
> performance improvements.  This will only be possible when the steps are
> really separated.  Then, memoizing variable locations in the memoize_foo
> functions will be possible, which simply can not work at the moment:  One
> reason is the re-writing of internal defines, which disallows the
> memoization of variables until the expansion phase is completed.

I don't know if you *are* worrying about the performance cost right
now, but if you are, I'd say don't.  Even if guile stays 20% slower
for a while, the long term benefits (and potential speedups) of this
work far outweigh the medium-term performance cost.

BTW has anyone else played with valgrind
http://developer.kde.org/~sewardj/docs/manual.html?  I'm planning to
play with it, but so far have only had a chance to see that it doesn't
like some of our ptr manipulations.  I also wonder if cachegrind might
be able to tell us anything useful...

> I have, however, not taken care of keeping track of debugging
> information so far.  That is, I would like to hear suggestions about
> how this should be done, since I don't have looked into that issue
> yet.  If someone is interested to give the stuff a review (with
> respect to the debugging issues or just generally), I would be glad
> to send you the patches for eval.c and eval.h.

I don't really know a lot about how debugging's being handled now, so
I'm not the best person to comment here.

> If the debugging stuff is worked out, it could even make sense to
> submit the changes so far to allow for a broader testing in the head
> branch.

Absolutely.  Actually I'd even say that if the debugging info is not
worked out, but if we think it *can* be worked out within a couple of
months, and if everything else is OK, then perhaps you should go ahead
and merge.  Your work will definitely get more attention in HEAD.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD