Status of the expander on Chez:

The expander running on Chez can expand itself

The expander proper runs at about the same speed in Racket and Chez; however, Chez’s compilation takes about as much time as the expander, so something like loading racket/base from source takes twice as long

Modules that go through the Racket expander are translated to Chez in a way that doesn’t support cross-module optimization; that’s sometimes a 20% hit (e.g., on the regexp implementation), but I don’t think it’s much of an effect for the time to load racket/base (because disabling cross-linklet optimization in Racket has a minor effect)

At this point, I’m not aware of any starting library or piece of the translation (besides cross-linklet optimization) that’s incomplete or done in a bad way, at least for loading racket/base

So, maybe this is a good point for others to take a look

I seem to remember hearing that the Chez compiler was really fast …

Maybe I’m doing something wrong, or maybe it’s just that everything’s relative

In any case, I’m not too worried about compilation times; the point of this experiment is to make the expander proper twice as fast

From the initial profiling I did a few days ago (I’m trying some more measurements now) my first guess is that we’ve traded slower HAMTs for faster other things

I’m not convinced that HAMT performance is a big effect. If I make hamt-set twice as expensive by doing its work twice, then load times and memory use don’t see to change all that much

But the expander on Chez is allocating 2–3 times as much memory (not counting compilation) as the expander on Racket, and that seems like a clue

it may be that the counting nature of Chez’s profiler (rather than measuring execution time) is throwing me off