This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Making Guile slower?
"Greg J. Badros" <gjb@cs.washington.edu> writes:
> We find performance bottlenecks the way that any good programmer
> finds them--- we profile and only optimize the parts that matter.
> If you concede that the general common case is no problem, then
> there's no worry that it's an all-around 2% slowdown -- it'll
> instead be an isolated fixable issue.
Note that macros are highly resistant to profiling.
> Using SCM_STRICT_FOOP won't improve readability-- it just adds
> another decision for programmers to make (choosing between STRICT
> and SLOPPY) that we can and should avoid because it's something
> better left to the optimizer.
Considering the number of times my code crashed because I left out
SCM_NIMP, I have to agree with this sentiment. I don't mind the
(hypothetical) slowdown in this case.
> > I don't care if Guile has actually gotten slower or more unstable
> > or not, the possibility alone that it might be the case is
> > troubling enough to me.
This means that we need a good coverage/benchmark test suite, rather
than conservative development approach. At least with SART, even
though my test battery is far from comprehensive, it helped me catch
the bugs almost as soon as I introduce them.
--
How to eff the ineffable?