Re: guile/guile-core/libguile async.h coop-defs.h ...

[Maciej Stachowiak <mstachow at alum dot mit dot edu>]

Mikael Djurfeldt wrote:
> 
> "Greg J. Badros" <gjb@cs.washington.edu> writes:
> 
> > It was preceded by some discussion -- see the thread started at:
> >
> > http://sourceware.cygnus.com/ml/guile/1999-12/msg00229.html
> 
> It is indeed precarious first to quit reading the guile list, and,
> then, complaining that there hasn't been discussions...  Why is
> life so complicated?  :(
> 
> > The "massively" is only until I remove all the spurious SCM_NIMP() from
> > the guile source.  Once that is done, it'll be a rare case where the
> > code expands any differently than before.
> 
> I'm thinking about the cases where the NIMP test is unnecessary to do.
> I hope, at least, that someone will go through the evaluator and put
> in sloppy versions of the tests there.
> 
> > And I reiterate that I got *no* negative feedback
> 

I wasn't able to chime in at the time, but I think the change is
generally good. However, I think it would be a good idea to follow
the policy of checking changes that may have a significant effect
on performance by profiling the code before and after (in the
future, prefferably before checking in). I am forced to agree
with Mikael's `slippery slope' argument about small incremental
performance hits, and we should be on the lookout for that
sort of thing.

Of course, this begs the question of how much of a performance hit
is acceptable, and for what tradeoff.

In this case, if it is really true that the tests were ever done without
a SCM_NIMP() immediately preceding, I would expect it was only a very
few places. Most likely then, either it won't matter to overall performance,
or those few places are the critical places where it's really needed, and
using sloppy versions there will not have a great averse effect on clarity.

I see some people have already started posting numbers to the list, we
need to figure out what those mean.

 - Maciej