6.8.5 When to delete and smash packages

Note: In general, you are advised against deleting or smashing packages unless it is absolutely necessary. Always try to reduce the image size as much as possible by treeshaking first.

If an application does one of the following things, packages are involved and you must consider keeping them in the application:

1. Makes an explicit reference to a package by some of the package functions, for example, intern , find-symbol and so on.
2. Uses the reader, with read or any of the other reader functions.

These functions make reference to a package (either *package* or one given explicitly) whenever they read a symbol.

3. Printing a symbol with the format directive ~S .

The format function prints the symbol with a package prefix if the symbol is part of a package.

4. Loading a file, whether compiled or interpreted.
5. Using the function symbol-package .

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.

However, if symbols in your packages are referenced through complex data structures, making it difficult to track references down, smashing may still prove useful.