[plt-scheme] Performance Targets for MzScheme

From: Daniel Silva (daniel.silva at gmail.com)
Date: Thu May 13 04:24:11 EDT 2004

On Wed, 12 May 2004 21:47:37 -0700, Brent Fulgham <bfulgham at debian.org> wrote:
> On 2004-05-12 18:10:39 -0700 Matthias Felleisen <matthias at ccs.neu.edu>
> wrote:
> > [I was hoping you'd read the thread.]
> >
> > So this shows that the problem is with srfi's. They are coded in
> > Scheme, and
> > what you're measuring is the interpretation time for each call to
> > split and
> > all the Scheme calls within. For each function call, the interpreter
> > "loops"
> > once (roughly). If, on the other hand, you call a "native" C
> > function, you do
> > ONE function call. Period. Period.
> Interesting.  IIRC, there's nothing about an SRFI that *requires* it
> to be implemented in Scheme.
> In fact, I'm pretty sure MzScheme satisfies a few SRFI's
> "out-of-the-box" as part of its core
> system.
> So we have a few options:
> 1.  Code SRFI's as C code that can be linked into MzScheme.
> 2.  Extend/complete the mzc compiler so that it can produce libraries
> with C-ish speed.
> 3.  Wave our hands at this "simple matter of programming" and continue
> on with our lives.
> Matthias, you say "Until we have a compiler."  Does this mean work
> progresses on a compiler, or
> are you just referring to an unknown future?
> Matthew -- the OpenGL bindings seem to consist of a mixture of C and
> Scheme code.  Would
> a reasonable approach be to identify low-hanging fruit like
> "string-tokenizer" and include them
> as native modules for the SRFI's?
> MzScheme is a great system -- but to be competitive for real world
> work we need to keep performance
> at a reasonable level.  If we can't use the tools that exist in the
> system (e.g., SRFI's) we lose a
> good deal of the elegance and utility of the language.
> I think I'll play benchmarks for a bit, then see if I can help with
> some library additions (assuming that
> won't be soon swept away by a blazing new PLT compiler, that is!)  :-)
> -Brent


Why not use regexp-split?  That's faster than string-tokenize.  Plus,
method dispatch is slow enough in Python that the difference in this
one primitive should be amortized.


Posted on the users mailing list.