This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Making Guile slower?


[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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]