Re: MEMOIZE_LOCALS (fwd)

[Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de>]

On Thu, 27 Jun 2002, Thien-Thi Nguyen wrote:

>    From: Dirk Herrmann <dirk@ida.ing.tu-bs.de>
>    Date: Thu, 27 Jun 2002 23:24:56 +0200 (CEST)
> 
>    I posted this to the guile-devel list, but I think it could be of
>    interest to people on the guile-user list as well.  So far, I have
>    got positive feedback from Marius for the change indicated below.
>    Thus, I urge people who disagree to this change to speak up.
>    Otherwise I will go ahead and remove the MEMOIZE_LOCALS macro.
> 
> this is a good opportunity to put in place performance testing framework
> so we can see what kind of impact changes like this have.  you can make
> statements like "benchmarks/memoize-locals.test shows 3% degradation w/
> this change in local testing".  people can then learn to judge whether
> or not such a change is under their noise threshold, and over time learn
> to trust your methods.  any plans to do this?

While in principle a performance testing framework is a good idea, it
won't help at all in the case discussed above:  The change, if applied as
suggested above, will only remove code that (if my assumptions about
people not making use of the MEMOIZE_LOCALS macro are right) is not
compiled into guile anyway.  Thus, the intention of the change is to
simplify the code by removing a lot of dead #ifdef code parts, making the
relevant parts of the code better readable.

Apart from this, I think there has been discussion about a benchmark suite
from time to time, but I can't tell about the current state.  Personally,
I don't have any plans to work on such a thing, but I would sure
appreciate if someone else likes to do so.  Performance is certainly an
important quality for software, but it is not the only one.  My personal
interest is on code readability, architectural cleanlyness, ease of use
(by means of providing a consistent and simple API) and such qualities.

Regarding my 'methods', I don't think there is much need to justify them.
Typically I think of ways to improve guile, suggest changes and discuss
with people whether these changes will make sense or not.  If there is a
consensus and I find the time (time is the most critical part!), I will
apply the changes.  So far, there have been only few complaints :-)

Best regards
Dirk Herrmann


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user