cache-watchlist generates wrong keys, effectively turning caching off
Closedopened 5 years ago by sorawee · 11 comments
Reference in New Issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
In my project I have:
and the following setup:
When I render page
common/common.html.pm, the key that is used for caching (as in
(subA/rkt/tags.rkt . 0).
This is bad because:
subA/rkt. The modified time is 0 because
subB/b.html.pmwhich similarly calls
common/common.html.pm. Even though
common.htmlis already cached, the cache is not getting hit because the keys are different. E.g.,
(subA/rkt/tags.rkt . 0)vs
(subB/rkt/tags.rkt . 0).
Empirically, in my project after I take
raco pollen reset; raco pollen renderspeeds up by at least 20 seconds.
I know I recommended the
resolve-module-pathtechnique in the Pollen docs. On reflection there seems to be a wrinkle: I see now that it resolves path strings like
"rkt/tags.rkt"relative to the current directory (which moves around during a pollen render). So maybe it’s not a reliable technique. Does this version of the
setupmodule fix your problem?
That works, thanks! However, I also discover another bug.
Consider the above situation except that I rename
subB/b.xml.pm. When rendering
subB/b.xml.pm, the cache key for
common/common.htmlseems to be:
But when rendering
subA/a.html.pm, the cache key for
preventing the cache to get hit.
Is there any reason that the extension is a part of the cache key?
Right — for
polyfiles the cache key includes the
current-poly-targetbecause it might affect how the
Oh I see, it’s not a
polysource. Well let me check.
I’m not seeing the file extension in my cache key for
common.html(assuming I’ve simulated your situation accurately)
#lang multi-fileis a nice way of making test cases that need to generate multiple files & directories.
It's actually a
polyfile. I simplified it to
.html.pmwhen I wrote the comment. So you are totally right. I guess it makes sense...
Thanks for pointing out to
#lang multi-file. This looks really useful.
Would you mind updating the documentation regarding
resolve-module-path? After that I would considered this issue resolved.
A warning regarding the interaction between
polyand caching in the documentation would also be nice.
I ended up writing this macro:
so that I don't need to
define-runtime-pathover and over and need to come up with id names. Do you think that the library should provide a macro like this? It's also more safe (if you mistype
define-cache-watchlist, it would result in an unbound id error, rather than a silent "configuration doesn't work"... speaking of it, can't we convert all setups to use parameters to make them safer?)
No, because the
define-runtime-pathtechnique is one possibility of many. The
cache-watchlistdoesn’t care how the complete path is generated. For instance,
resolve-module-pathmay still be the better choice, if you want to depend on an installed module.
(PS this macro won’t work as written.)
How so? It seems to work for me.
Somewhere (either in the macro definition environment or the macro itself) there needs to be a
Right, I did
require racket/runtime-pathoutside of the macro.
Thanks again for all your help!