While xf_permission_combination isn't very large, xf_permission_cache_content can grow to be very large.
On-disk compression can make fairly big difference for one of my sites;
[CODE]# du -hs --apparent-size /var/lib/mysql/xenforo/xf_permission_cache_content.ibd
364M /var/lib/mysql/xenforo/xf_permission_cache_content.ibd
# du -hs /var/lib/mysql/xenforo/xf_permission_cache_content.ibd
55M /var/lib/mysql/xenforo/xf_permission_cache_content.ibd
[/CODE]
Not storing "false" permissions, would reduce the xf_permission_cache_content size a measurable chunk. And improve memory usage when a large number of xf_permission_cache_content entries are loaded.
This is because php's memory usage skyrockets when a very large number of xf_permission_cache_content 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 xf_permission_cache_content 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.
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
