The compiler in version 4 takes multiple seconds to compile examples/disasm.st
, which is only 215 lines long. I started looking into why, and this issue is just to record what I found for anyone else who might want to dig further.
The obvious guess is that this is the first version where the compiler is itself in Smalltalk instead of C, and Little Smalltalk is just that slow at everything. But that's not the reason: on a simple benchmark it executes millions of method calls per second.
I extended lst4 with call-count profiling -- unfortunately, the results don't really clear it up to me. Here are the methods called in compiling examples/disasm.st
, with the count of how many calls for each:
callcount.txt
(Some of the numbers are inflated slightly because it also recorded counts for compiling the code that dumps the counts. But those mixed-in counts are under 4% of the counts for disasm.st, so I'm not going to the work to split them out.)
Clearly it's heavy on the string and array ops, but it's not obvious to me what higher-level code is making them pile up. A fancier profiler that also tracked the callers of the heavily-called methods would help. Or maybe just interrupting execution at random moments and printing the backtrace.
In summary: compiling a 5k-byte source file needs millions of string and array operations -- on the order of a couple thousand for each byte. There are some obviously quadratic algorithms in the compiler, but I couldn't see a likely candidate for which, on casual inspection.