Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0.1
    • Fix Version/s: 2.0.2
    • Component/s: Libraries
    • Labels:
      None
    • Affected Branches:
      MOODLE_20_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE
    • Rank:
      16006

      Description

      While making other changes (MDL-25981) I noticed that my new code was very slightly slower, and that one reason for this was that I improved a few parts of code by using moodle_url that had previously been hacked together with strings.

      Using Eloy's profiler (ie these are not random changes!) I have optimised moodle_url as follows:

      1) In params(), it makes 3 checks for dubious types in use for array keys, in order to throw an exception if the wrong type is used. I have added a first check for is_string which skips the other 3 checks (so in most cases it does 1 check instead of 3 checks).

      This improves constructor performance by approx 40% in my test case, saving about 1.5ms on a course page view.

      2) In get_query_string() I have made it only call merge_override_params if there actually are any. Since there usually aren't, this saves function calls and the work done in that function.

      This improves ->out() performance by approx 20%, saving about 0.8ms on a course page view.

      While a saving of 2.3ms (approx 1%) is not that big a deal, it pretty much makes up for the similar slowdown that my other improvements cause, and every little helps right? Especially as, if anything, we will probably increase use of moodle_url in future.

        Activity

        Hide
        Sam Marshall added a comment -

        I've done more robust stats based on aggregate of 5 runs (also after fixing my code for part 1, which was wrong). I now think this only improves performance by a bit over 10% in both cases, saving approx 10 microseconds per run of each function. Both functions are run approx. 100 times on the course page, so that still translates to about 2ms saving as stated before.

        Show
        Sam Marshall added a comment - I've done more robust stats based on aggregate of 5 runs (also after fixing my code for part 1, which was wrong). I now think this only improves performance by a bit over 10% in both cases, saving approx 10 microseconds per run of each function. Both functions are run approx. 100 times on the course page, so that still translates to about 2ms saving as stated before.
        Hide
        Petr Škoda added a comment -

        thanks, closing

        Show
        Petr Škoda added a comment - thanks, closing

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: