Back in the early 2000's, IIRC, Squeak Smalltalkers succeeded in getting a Smalltalk runtime down to 385 kB. Haters still complained about it being "too fat." There was an R&D project which got one Smalltalk image for a Unix-style command line utility to 45 kB. Back in those days, the standard class library for a VisualWorks Smalltalk image was about 12MB on disk.
In contrast, Perl had a runtime of something like 768 kB. Yet, VisualWorks could load its runtime faster, if you tweaked things, like shutting off the boot-up chime and notifier dialog.
> Yet, VisualWorks could load its runtime faster, if you tweaked things
For the same reason that Emacs loads quickly: the "image" is (an abstracted, runtime-dependent equivalent to) a memory dump. Perl has to parse Perl code when it starts up; Smalltalk just "is" Smalltalk when it starts up. Like booting up a DBMS where the DB already has data in it.
Honestly, I'm kind of surprised more modern languages/runtimes don't take this approach. The Smalltalk approach would work exactly as well for e.g. Ruby.
It leads to a lot of issues with the end design of everything. You either have to reconstruct the heap and all the pointers involved, or it has to be loaded at a known address. With things like ASLR, and a bunch of other security features this ends up difficult or impossible to do directly anymore. Along with that, it also means that the runtimes aren't cross-compatible at load time so weird differences might leak out (little or big endianess, etc.). It leads to a lot of headaches because of changing systems underneath it.
