This section discusses the circumstances in which you might want to throw symbols and packages out of the application, by deleting or smashing them.
After the package is deleted, its symbols continue to exist, but because they are no longer interned in a package they become eligible for collection at the next garbage collection. They survive only if there are useful references to them elsewhere in the application.
You can pass
deliver a list of packages to delete with the keyword
After the package is smashed, the symbols continue to exist, but all the information they contained is gone. By being uninterned they become eligible for garbage collection. Also, the chances of any objects they referred to being collected are increased.
find-symboland so on.
reador any of the other reader functions.
Fortunately, most applications are unlikely to do these things to more than a small number of packages. You should, therefore, be able to delete most packages without breaking the application. When you know that none of the symbols belonging to a package are used, you can go one step further and smash it.
Smashing a package guarantees space savings where deleting it would not. Even in a case where a symbol is referenced but unused, because it has been smashed you still regain space taken up by objects hanging from slots for function definition, value, property list and so on.
You do not usually gain much by smashing your own packages that you would not gain by just deleting them -- you are after all unlikely to have included an entire package of symbols in your final application if you know it is not going to use them. The real benefits of smashing can be seen when it is performed on the system's packages, some of which may be entirely irrelevant to your application. In addition, you are unlikely to gain very much by deleting a package that you would not gain by treeshaking. In general, you should try to avoid either deleting or smashing packages explicitly.
LispWorks Delivery User Guide - 10 Aug 2017