As the PHPdoc comment on question_has_capability_on says:
- @param integer $cachecat useful to cache all question records in a category
So, $cachecat does not cache anything, it tells the function to cache all the data from a particular question category with a couple of DB queries, to save DB queries on future calls to this function.
The actual caching is done by
static $questions = array();
static $categories = array();
static $cachedcat = array();
The point is that to check permissions to do things to a question, you need to know question->createdby and question->category->contextid.
That is really a trivial case. The more interesting question is
- What sort of caching could questionlib be doing that it does not already do, in order to make the biggest difference?
Loading question definitions
There is a significant un-solved problem: load_questions, or rather get_question_options which it calls.
Typically, that is used any time someone is attempting or reviewing a quiz, and the $questions array is all the questions in the quiz, or at least on the current page of the quiz.
> _tidy_question -> question_bank::get_qtype($question>qtype)->get_question_options($question)
and that get_question_options typically does a few DB queries.
So, we are doing a loop which does a few DB queries per question in the body of the loop, which is a classic performance failure.
This has been a known problem for ages, but it is only recently that I realised that effectively this is a problem that we already solved in Moodle years ago.
The place we have solved this is the modinfo cache for courses. Loading the key data for a module (e.g. name) takes several DB queries per module, so we cache the data in serialised form in course.modinfo.
We can do exactly the same for question definitions, except that for question definitions, I would be inclined to do it slightly differently. For modules, we cache all the data for all the modules in a course in one entry in the course table.
For questions, I think it is better to cache the data per-question, so we either add a column 'definitioninfo' (or something like that) to the question table, or, my preferred option at the moment, we add a new table question_definition_cache with columns id, questionid, and serialisedquestiondata. Anyway, that would hold the result of calling load_question in PHP serialised form.
But obviously, even though I have thought that through, I am not planning to implement it until after I have seen how MUC goes.