I have some financial support for working on both caching and permissions for 4.7. I've been talking to Berklee about ideas I have to improve the simple caching db api pI did for Greenpeace (which Berklee uses heavily in their customized deployment of dotLRN). Berklee's made some improvements of their own, too.
Clearly there's no time to fix things for 4.6.
Peter, the memoize caching avoids repetitive calls to the db for a particular user. The initial page load is still slow of course but subsequent views are heavily cached. Not just permissions but some vital portal stuff are being cached on SSV2. Sloan has as a goal trying to some of this moved into the "real" dotLRN code base.
Simon, memoize is great for procs that return values from the db. The caching db api I hacked together for GP caches db_multirows, db_list, db_list_of_list and the like and is very simple to use (just add "-cache" to the db_* calls you want cached). While it's not general purpose as written for Greenpeace, our work there and Berklee's use makes it clear that it can be made to work very well and very easily.
Of course we'll have public dicussion before any final decision is made on just how to most effectively add caching.
However ... caching only reduces the time needed to generate a query result after the first query result is produced. The first query needs to be reasonably fast, too - and that's where permissions really lets us down. Simple permissions scale well, but group-based permissions don't (and dotLRN heavily depends on relational segments, which can be thought of "subsets of groups"). IMO OpenForce made the right decision in using relational segments, they work very well. They were more or less ambushed by the unknown fact that group/relseg perm checking scales much less well than direct permissions.
