Re: Why is guile still so slow?

[rixed]

-[ Wed, Oct 12, 2011 at 10:54:11AM -0400, John Lewis ]----
> I don't understand while Guile is so slow. According to these
> benchmarks 
> http://www.cs.utah.edu/~mflatt/benchmarks-20100126/log3/Benchmarks.html
> GNU Guile is running about a order of magnitude slower than Bigloo,
> Chicken, Gambit, Ikarus, Larceny, MIT, and Racket(PLT) with most task.

Bigloo, Chicken and Gambit compiles to native code (through C).
I can't tell for the others. This simple fact certainly accounts
for most of the difference.

Also, some (Bigloo for sure, maybe others) have type annotations while
guile currently have not (although this was discussed recently).

Also, as guile now relies on bdwgc for the GC it might suffer from
conservative GC (while other scheme might use a dedicated GC, which
can additionally perform some life span analysis to reduce useless
collection - IIRC Gambit does this... or is it Stalin?). bdwgc is
certainly a big win with regard to code complexity, though.

> the sluggishness of Guile
> is going to make it impossible to use to for application development
> no matter how Ubiquitous Guile currently is.

If so, then there is no application written in Python, Ruby,
Javascript... :-)
Joking aside, maybe guile is too slow for writing whole apps in it,
but it's primary goal is to be an extension language, a companion for
another C/C++ program, or at best an orchestrator of business oriented
code. So performance is not the primary objective. For instance, I'm
using guile as an extension language for a low-level commercial product
for which speed matters, and it's perfect for what it does (configuring
the software, mostly). Using another scheme app would have been less
convenient since they are less easy to link with C code.