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

With filter_ouglossary:

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.

With filter_glossary:

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

The problems with the code

I think there are two fundamental problems here;

1. 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.
2. 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.