While the inclusion of the relation would fix it, I've always thought that the xf_permission_combination table should be cached in the data registry. It's not terribly large, it changes very rarely and is queried multiple times a second even on a moderately trafficked site (could be 100+ times per second on a high traffic site)... every request more or less to get the guest user permission combination.
isn't very large,
can grow to be very large.
On-disk compression can make fairly big difference for one of my sites;
# du -hs --apparent-size /var/lib/mysql/xenforo/xf_permission_cache_content.ibd
# du -hs /var/lib/mysql/xenforo/xf_permission_cache_content.ibd
Not storing "false" permissions, would reduce the
size a measurable chunk. And improve memory usage when a large number of
entries are loaded.
This is because php's memory usage skyrockets when a very large number of
are loaded, as php array format quite memory heavy when you've got hundreds of keys. Classes don't really save you much either.
The linked 'Cache Permission Check' add-on caches to redis all the
rows for a permission_combination_id pruned of "empty/false" permissions which saves about 30% memory usage. That add-on also goes further and scrapes out permission table joins for a large number of entity finders, which reduces SQL query result sizes, as they just hit the redis cache instead.
Maybe I'm missing something, but it looks like it would be fairly easy to do it... define a data registry entry, read from the data registry in
\XF\PermissionCache::getGlobalPerms(), reset data registry in
\XF\Job\PermissionRebuild, and that's it? Maybe I'm missing something. Would save a lot of queries on any site regardless.
The tricky part is the cache invalidation. My add-on ends up extending +10 points to trigger cache invalidation in the various required ways to make it robust