This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Making Guile slower?
- To: guile at sourceware dot cygnus dot com
- Subject: Making Guile slower?
- From: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Date: 16 Dec 1999 09:10:18 +0100
- Cc: mvo at zagadka dot ping dot de, jimb at red-bean dot com, orre at nada dot kth dot se
- Cc: djurfeldt at nada dot kth dot se
- References: <19991216034642.19077.qmail@sourceware.cygnus.com>
[I'm resending this message under a more proper subject line. Also,
one additional thing: Note that we can't make some proper mix of
these two approaches---that would be totally confusing. We have to
decide whether to always make these, sometimes unneccesary, tests for
nonimmediateness or to always give the programmer control over this.
And, btw, a "fair" test is to find that worst-case situation which is
still a computation of reasonable use. You have to find code in
Guile where this change matters.]
gjb@sourceware.cygnus.com writes:
> * *.h: Use SCM_NIMP(X) && in all the FOOP macros.
This is a very fundamental change which I think should have been
preceded by discussion. In any case, it should have been preceded by
benchmarks (and *fair* benchmarks).
I ask you to revert this change until these things have been settled.
I realize that this change makes application code safer. But the scm
interface does *not* have as primary purpose to be an application
interface. That is the role of the gh interface. The primary role
for the scm interface is to implement Guile itself.
We have never had trouble with maintaining the explicit distinction
between immediate and nonimmediate values.
It is important that we don't make changes which can adversely affect
performance without knowledge of these effects. What you're doing now
is to massively introduce more computations into many operations.
This may be right, but we don't know that yet.
[Now I hope that other people will pick up and defend this position,
'cause I simply can't right now.]
/mdj