Update on performance

From: Andrew Joseph Kompanek <ak10+_at_andrew.cmu.edu>
Date: Fri, 14 Apr 1995 02:44:54 -0400 (EDT)

Don't know if folks are interested but I got some results that convinced
by that indeed the overhead is in the scheme reader. Okay, so this might
be obvious but I figured a there might be some significant overhead
associated with manipulating data structures.

At any rate, my parser essentially simply runs through a
simple recursive list-like structures at the bottom of which
are delimited primitive data types for numbers and strings and
turns it into an equivalent scheme nested list structure (guess that kind
of sounds like the scheme lexer...)

When I implement almost exactly the same algorithm in C and
build the SCM return value, it runs about 80 times faster.

Which made me wonder... is there any way to do some sort of
compilation in STk that would have saved me the trouble
of manually writing this code?

It doesn't seem very difficult to build a compiled version of
a function which has all the "reader" preprocessing done.
(this may sound naive... I admittedly have never really thought about
or read about this). Or, even (okay, this seems messy) writing
Scheme->C which knows about the underlying API for STk primitives.

Received on Fri Apr 14 1995 - 08:46:40 CEST

This archive was generated by hypermail 2.3.0 : Mon Jul 21 2014 - 19:38:59 CEST