The cache should ideally be per source-registry entry; and managed by the same entity that manages said entry. Thus, I was thinking of an optional second form in cl-source-registry.conf file. Or a separate .cl-source-registry.cache file.
I saw that. i’m ambivalent about the complexity.
Checking for .cl-source-registry.cache in collect-sub*directories-asd-files should be straightforward. NB: If you're going to hack these things, please use the faster-registry branch. You don't have an account on common-lisp.net yet, but it looks like, after a year, it's still the same machine that some people were angry about and calling for the replacement of, and I happen to be root there, so I can open you an account and give you write access to the asdf repository (if Robert agrees) — send me your ssh public key.
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.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org None are more hopelessly enslaved than those who falsely believe they are free. — Johann Wolfgang von Goethe