Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-47962

Major room for performance improvement in filter_glossary

    Details

    • Type: Bug
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.7.2
    • Fix Version/s: None
    • Component/s: Filters, Glossary, Performance
    • Labels:
    • Workaround:
      Hide
      1. Go to your glossary
      2. Click Glossary administration > Filters (or use cog menu in boost and click Filters)
      3. Turn off glossary auto linking.
        Other pages will still be auto linked, just not the glossary to itself
      Show
      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
    • Affected Branches:
      MOODLE_27_STABLE
    • Pull from Repository:
    • Pull Master Branch:

      Description

      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.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Votes:
                  4 Vote for this issue
                  Watchers:
                  8 Start watching this issue

                  Dates

                  • Created:
                    Updated: