|(require pollen/cache)||package: pollen|
The slowest part of a Pollen render is compiling a source file. Because Pollen allows source files to be edited and previewed dynamically, these files get recompiled a lot. Therefore, Pollen stores copies of the exports of source files — namely, whatever is stored in doc and metas — in a cache so they can be reused.
In each directory of your project, Pollen writes cache files into a subdirectory called "compiled". The files are stored on disk so they can be reused between sessions. If you delete files within a cache directory (or the whole thing), don’t worry — everything will get regenerated. (However, I don’t recommend trying to read or write directly to any "compiled" directory, as the implementation details of the cache are subject to change.)
Though the cache will be populated as you use Pollen, you can also preheat it with raco pollen setup. This command will load all your source files into the cache. This will give you the snappiest performance during an interactive session with the project server.
If you want to reset all the compile caches, use raco pollen reset.
(module setup racket/base (provide (all-defined-out)) (define compile-cache-active #f))
Pollen also caches rendered output files, so if you want to disable all caching — thus forcing everything to recompile, every time — you should also disable the render cache by overriding setup:render-cache-active:
(module setup racket/base (provide (all-defined-out)) (define compile-cache-active #f) (define render-cache-active #f))
Be warned that this will make your rendering much slower. But you will be guaranteed an entirely fresh recompile each time, which can sometimes be useful in development.
The compile cache tracks the modification date of the source file, the current setting of The POLLEN environment variable, and the modification dates of the template and "pollen.rkt" (if they exist).
It does not, however, track every possible dependency. So in a complex project, it’s possible to create deep dependencies that aren’t noticed by the cache.
Unfortunately, there’s no way around this problem. For the cache to be useful, there has to be a limit on the horizon of dependency checking. To capture every possible dependency, the cache would have to recompile every file, every time — which would be equivalent to not caching at all.
Those who need that kind of deep dynamism can disable the cache.
Despite their names, these functions actually rely on setup:main-export and setup:meta-export (which default to doc and metas). Thus, if you override those names, everything will still work as expected.
If you want the speed benefit of the cache, you should use cached-doc and cached-metas to get data from Pollen source files in preference to functions like require, local-require, and dynamic-require. Those will also work. They’ll just be slower.
(reset-cache) → void?