Next: Configuration API, Previous: Search Algorithm, Up: Controlling where ASDF searches for systems [Contents][Index]
The implementation is allowed to either eagerly compute the information
from the configurations and file system, or to lazily re-compute it
every time, or to cache any part of it as it goes.
In practice, the recommended source-registry eagerly collects and caches results
and you need to explicitly flush the cache for change to be taken into account,
whereas the old-style *central-registry* mechanism queries the filesystem every time.
To explicitly flush any information cached by the system
after a change was made in the filesystem, See Configuration API,
and e.g. call asdf:clear-source-registry.
Starting with ASDF 3.1.4, you can also explicitly build a persistent cache
of the .asd files found under a tree:
when recursing into a directory declared by :tree and its transitive subdirectories,
if a file .cl-source-registry.cache exists containing a form
that is a list starting with :source-registry-cache followed by a list of strings,
as in (:source-registry-cache "foo/bar.asd" "path/to/more.asd" ...),
then the strings are assumed to be unix-namestrings designating
the available asd files under that tree, and the recursion otherwise stops.
The list can also be empty, allowing to stop a costly recursion in a huge directory tree.
To update such a cache after you install, update or remove source repositories,
you can run a script distributed with ASDF:
tools/cl-source-registry-cache.lisp /path/to/directory.
To wholly invalidate the cache, you can
delete the file .cl-source-registry.cache in that directory.
In either case, for an existing Lisp process to see this change,
it needs to clear its own cache with e.g. (asdf:clear-source-registry).
Developers may safely create a cache in their development tree,
and we recommend they do it at the top of their source tree if
it contains more than a small number of files and directories;
they only need update it when they create, remove or move .asd files.
Software distribution managers may also safely create such a cache,
but they must be careful to update it every time they install, update or remove
a software source repository or installation package.
Finally, advanced developers who juggle with a lot of code
in their source-registry may manually manage such a cache,
to allow for faster startup of Lisp programs.
This persistence cache can help you reduce startup latency.
For instance, on one machine with hundreds of source repositories,
such a cache shaves half a second at the startup
of every #!/usr/bin/cl script using SBCL, more on other implementations;
this makes a notable difference as to
their subjective interactivity and usability.
The speedup will only happen if the implementation-provided ASDF is recent enough
(3.1.3.7 or later); it is not enough for a recent ASDF upgrade to be present,
since the upgrade will itself be found but
after the old version has scanned the directories without heeding such a cache.
To upgrade the implementation-provided ASDF,
see Replacing your implementation’s ASDF.
Next: Configuration API, Previous: Search Algorithm, Up: Controlling where ASDF searches for systems [Contents][Index]