Any insta-theories for where other half second comes from?
If you mean the second half of cl-launch's startup time, I fear it might be a combination of shell and CL compilation overhead, but I admit I haven't tried timing where the time is going. You're welcome to investigate. At some point, I was thinking of translating cl-launch to CL and having it output a bootstrap script to make itself. Then it would have a "fast" mode that loads code onto the cl-launch image, rather than start a new process (with maybe a different CL implementation) to implement the requested software. At that point, maybe Xach's buildapp is a better starting point. Or not.
The other half of cl-launch's startup time is spent in CL, and is definitely a performance bug: % time env SBCL=/bin/true cl -ip 1 env SBCL=/bin/true cl -ip 1 0.03s user 0.02s system 102% cpu 0.045 total % time env CL_SOURCE_REGISTRY="/does/not/exist" cl -ip 1 env CL_SOURCE_REGISTRY="/does/not/exist" cl -ip 1 0.43s user 0.06s system 98% cpu 0.494 total
Inserting a few (time) forms and enabling verbose loading, I find that the cl:load'ing of cl-launch itself is taking most of the time, and the most time in that is loading then upgrading asdf, i.e. loading the fasl's for it. I'm not sure how to speed THAT up; ASDF is big, and not likely to shrink significantly while preserving backward compatibility. SBCL also seems to be spending some notable fraction of the time compiling the cl-launch code itself, though most of the time is the fasl loading. Conclusion: FASt Loading is only so "fast".
PS: your topology.sh file has a ":" ; # ... comment as if it were a bilingual script, but it isn't bilingual. Also, the path /usr/local/bin/cl is not standard and neither is the -S argument.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "The Army is a place where you get up early in the morning to be yelled at by people with short haircuts and tiny brains." — Dave Barry