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: Making Guile slower?


Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> Greg Harvey <Greg.Harvey@thezone.net> writes:
> 
> [Interesting tests deleted.]
> 
> > And so on. In any case, I think it's a pointless bit of pennypinching
> > to worry about one test in the vast pile of code that is guile,
> > particularly if it makes it less likely to introduce bugs.
> 
> Now, firstly, I repeatedly forget that I'm not any longer a Guile
> developer but a Guile user, so you clearly have more say in this than
> I have.
> 
> Secondly, I've not said that it is a bad change.  I said it should be
> preceded by benchmarks and discussion.  My purpose is just to sound
> the alarm bell since what looks like an innocent improvement of the
> Guile macros is in fact something which needs a great deal of thought
> and consideration.

Well, I did think about it and said it was a good idea before he made
the change (it'd be somewhere in the list archives :), for two
reasons: first, we are only adding 2 instructions to every SCM_XXXP
test (an and, a branch). This by itself isn't enough, of course. The
important bit is that we aren't actually adding this to many
places. It's very rare, even in the evaluator, to have a test on a
non-immediate which is not preceded directly by SCM_NIMP; the worst
case I tried to exploit with that little test doesn't happen at
all. You'd never do that many SCM_XXXP's; you'd do a case on the type
after doing SCM_NIMP once.

-- 
Greg

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