To constrain memory we only cache a single question's answers.
A quiz must display this many answers, so it will not result
in undue memory pressure.
We now match on the full answer text rather than the first 255
characters. This removes the risk of matching questions with the
same start.
encode_backup_temp_info() and decode_backup_temp_info() have been
introduced to keep the info field encoding in one place.
Many locations used get_backup_ids_record() to obtain info, that
makes lots of calls to get_backup_ids_record() which can be slow.
We now complete all those inline by adding the info field to the query.
To reduce memory usage, all queries of that nature have been changed
to use get_recordset_*. gzcompress was introduced if available to minimize
traffic to/from the database and to decrease the memory required for caching.
The compression time is saved by the benefits in other places of having smaller data.
- Escaping steps arguments redirected to other steps
- Adding normalized-space() in all contains() assertions
- General xpaths review
- Convering provided xpath text strings to xpath literals
to avoid problems with arguments containing both single
quotes and double quotes
The cache is function local and testing against a large database
indicates 10k questions is a large category. Restore already
uses MEMORY_EXTRA and that will have enough space for the couple
of megabtyes a local sql hash will introduce.
For $this->groupedpaths, using a key is faster as there is
no need to do in_array searches.
Parent cache allows dirname calls to be substantially reduced.
2048 was chosen as a cache size as this class operates on chunks
of the restore at a time, 8k questions produces a parent cache of
about 500 paths and uses 300K of memory. Scaling up to 2048 will
use about 1.2M of RAM for really large restores. This is acceptable
for the 48% function call reduction and the 10% runtime improvement
seen.
There were still some differences between the php code
used in the issue and the php code generated by the
xmldb editor for the template tables. This commit put
both 100% in sync.
