What are the reasons Racket CS is, or at least used to be slower than Racket BS? Was the whole transition towards CS not primaritly to boost performance? Were expectations to high in this regard?
1. The big performance issues early on were compilation speed -- Racket had a simple JIT compiler that ran almost instantly.
2. Some rewritten parts of the system, such as IO, were initially slower, but have now been improved to catch up to the previous implementation.
3. Chez Scheme didn't support some performance features that Racket BC had, such as unboxed floating point arithmetic, parallel GC, or continuation marks. Those have been added to (Racket's variant of) Chez Scheme.
4. Racket's prior compiler was somewhat more competitive with Chez Scheme than we expected, particularly for larger and more Racket-idiomatic programs.
Flatt has written elsewhere that the motivation to use Chez was not speed per se but better maintainability and portability, and that required rewriting more of the C core in Racket itself [0]. Doing so would have slowed down all of Racket considerably, but by using Chez it became possible without a big speed penalty. At first there was such a penalty because the rewritten stuff was still slower than C, but with tuning that has mostly gone away.
They took the opportunity to move some of the infrastructure from C to Racket itself:
Mostly, we did reimplement the C stuff in Racket. The I/O
subsystem, the concurrency subsystem (which includes the
scheduler for “green” threads, Concurrent ML-style events,
and custodians), and the regexp matcher were all rewritten
in Racket. Those pieces followed the rewrite of the macro
expander in Racket.
So there was a slowdown until those pieces matured. But now they get the benefit of having all those pieces in higher level of abstraction and more accessible to Racket programmers.
To add to the other reasons - the CS compiler optimizes different forms and Racket is currently optimized for it's own compiler. To give a concrete example, taken directly from the racket blog [1]:
> For example, Racket BC makes dormant code relatively
cheap, so Racket libraries generate a lot of code. Future
Racket libraries will likely shift to take advantage of
Racket CS’s cheaper function calls and dramatically cheaper continuations. One day, probably, Racket BC will no longer be a viable alternative to Racket CS for most programs.
