>
>
> >Has anyone done any profiling? Some of the STk examples
> >are slow in places. I'm wondering if it's Tk, Scheme,
> >or, probably, both.
>
> Performance-wise, the Scheme part of STk is a dog; my rule of thumb is a
> factor of 100 slower than native code on programs that do a lot of...
A dog? My understanding of the relative performance of
different _interpreted_ languages lead me to believe that scheme (and
therefore STk) should be relatively efficient---please correct me if I
am wrong! Of course it will always be slower than compiled C code (is
this really what you were comparing it to when you say "native code")
but when compared to other interpreters (and especially Tcl) it stacks
up significantly better.
As a general rule of thumb (also) performance critical sections of
code should be coded in C (or other) and added to the interpreter as
dedicated new functions. (This was JohnO's original argument for
Tcl---but scheme is a much superior extension language.) This is
certainly the quickest (and perhaps even the best) solution to
performance problems encountered with STk but profiling is very
important to indicate exactly which sections of code should be given C
level support.
I believe the IIC (see kaolin) contribution contained some profiling
stuff though I have not used it...
A scheme->C compiler is still a great thing, but (I believe) mostly
for other reasons such as providing binary distributions, protecting
intelectual property etc.
--
------------------------------------------------------------------------------
Mr Andrew Dorrell
School of Electrical Engineering *
University of Technology, Sydney *
PO Box 123 *
Broadway NSW 2007 .
AUSTRALIA
* /---\ Whoo?
Phone: 61 2 9154 2395 (o o) /
Fax: 61 2 9154 2435 ( : )
email: andrewd_at_ee.uts.edu.au ^ ^
OR dorrell_at_ihf.uts.edu.au
------------------------------------------------------------------------------
Received on Sun Aug 04 1996 - 04:31:26 CEST