Next: , Previous: , Up: Controlling where ASDF searches for systems   [Contents][Index]

8.9 Caching Results

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 ( 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: , Previous: , Up: Controlling where ASDF searches for systems   [Contents][Index]