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

["Greg J. Badros" <gjb at cs dot washington dot edu>]

Maciej Stachowiak <mstachow@alum.mit.edu> writes:

> 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.

I, too, agree with it, but point out yet again that this is something
where the post-preprocessor code is virtually unchanged except in a very 
few number of places.

> 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.

Right, if they're even necessary.

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

Yep.

I just committed the change to remove the SCM_NIMP() from the
macro-invocation sites, so now useful benchmarks (and more importantly,
as thorough regression tests as possible) can be done.  I think next to
documentation, thorough regression tests are the most important thing
for Guile right now.

Greg