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]

Re: docstrings in Guile!


Daniel Skarda <0rfelyus@atrey.karlin.mff.cuni.cz> writes:

> > SCM_NIMP(x) && SCM_FOOP(x)
> > 
> > I don't think that there is that big of a performance win by not having
> > the SCM_FOOP's check SCM_NIMP (there are some places where the SCM_NIMP
> > is factored out into an earlier test that affects several branches).
> > 
> > I think we should fold the SCM_NIMP macro test into SCM_FOOP macro
> > definitions, and add a new SCM_F_FOOP (for *F*ast foop) or
> > SCM_SLOPPY_FOOP for the cases where we really want that test omitted.
> > Then things work right away (perhaps with a non-noticeable performance
> > degradation), and where performance *really* counts (based on profiling) 
> > we can switch to SCM_SLOPPY_FOOP.  Elsewhere we just eliminate the
> > SCM_NIMP eyesore.
> > 
> > Comments (before I just go run with this idea!)?
> 
>  I would like to propose to keep SCM_FOOP as it is and add new macros
> 
> #define GH_FOOP(X)	 (SCM_NIMP (X) && SCM_FOOP (X))
> 
>  which is more like gh_ interface - 
> 
>  There is a lot of code in which authors already checked X for NIMP so IMHO its
>  easier to get used to GH_ macros rather than rewrite all code already written
>  for Guile...

But that's the point:  you don't *have* to rewrite all existing code; it's 
just a performance optimization to rewrite the existing code, along with 
a simplification of that code.  (Plus it's pretty straightforward to
automate the removal of the "SCM_NIMP(x) &&" text).  As an added bonus,
all the bugs where SCM_NIMP(x) was *not* checked for disappear since
that check is no longer needed.  And places where the check is a
performance hit (few and far between) can be written to use
SCM_SLOPPY_FOOP to avoid the SCM_NIMP test when the code has that
invariant through some less obvious means.

I want the easy case to write to be the safe case to use, and for
existing code to be more likely to be bug free even at the slight
performance hit that can easily be retrieved.

Greg

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