Affects Version/s: 2.7.2
Fix Version/s: None
- Go to your glossary
- Click Glossary administration > Filters (or use cog menu in boost and click Filters)
- Turn off glossary auto linking.
Other pages will still be auto linked, just not the glossary to itself
Pull from Repository:
Pull Master Branch:
Pull Master Diff URL:
I am doing profiling on a big course containing a glossary with 480 terms.
I am comparing our custom filter_ouglossary, which does caching by caching the final result of fitering the input string, with standard filter_glossary
Total page-load time: 1.6s
Calls to filter_ouglossary::__contruct: 170ms (12 calls)
Nothing else shows up, which means it total less than 36ms.
Total page-load time: 3.2s
filter_glossary::filter: 1900ms (14 calls) - so this is all the difference.
This calls the following functions:
html_writer::start_tag: 560ms (5760 calls)
usort (calling filter_glossary::sort_entries_by_length): 420ms (12 calls, calling the comparator 49,000 times)
filter_phrases: 290ms (14 calls)
moodle_url::__construct: 260ms (5760 calls)
mod_glossary\local\concept_cache::get_concepts: 220ms (12 calls)
and everything else is small
I think there are two fundamental problems here;
- filter_glossary caches the data in the class instance, but on this page there is text from 12 different contexts, so we create 12 instances of the class which each load their own data. This code was implemented without a proper understanding of how text filtering acutally works. We need to load this data only once per courseid per page load.
- filter_glossary::filter renders the HTML for a glossary link to each term in the glossary, whether on not that will be used. Since most pages only contain a tiny fraction of the glossary terms, the HTML for the link needs to be generated on-demand. We need to change the filter_phrases / filterobject API so that fields like $hreftagbegin are accessed through a getter, so we can do lazy initialisation.