Since we currently have no accessrules that use $NODE, I'd leave $NODE out of the key. If we come up with accessrules that use $NODE, I'd have them set a flag saying to not cache the results.
That should make the cache both smaller and more effective. A hybrid approach would probably be possible (but, since the only specific use for $NODE that I recall hearing isn't needed, I'm expecting uses of $NODE to be exception and probably not much worth caching, so plans to use $NODE extensively would change that).
But more numbers would be interesting.
With the cache only per-page-hit, the size should usually remain small... But I worry that the-thread-not-to-linked-to or some other untested case could balloon things up.
Update: I got the modified patch to apply. So I've got new NodeBase.pm and HTML.pm queued up to be deployed but it's past bed-time so the deploy will wait 'til I can stick around.
- tye
In reply to Re^2: Proposed new behaviour of isGods and isApproved (per session cache) ($NODE in key)
by tye
in thread Proposed new behaviour of isGods and isApproved (per session cache)
by demerphq
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |