• I have been looking at the performance of my website using cachegrind on my computer to analyse what is happening on individual web pages. This analysis has highlighted a few issues:

    1) When using the “Upcoming Events”, grab_events is called against each possible day. As I am looking out the next 2 months, this is making 60+ calls against the calendar table on columns that are not indexed. Why can the function grab_events not accept a range of dates and then generate the list of “daily” events for the period? I recognise this would change some of the logic within the functions that use this function. The second issue with grab_events is the SQL query is over complex in that each call runs a SQL query which is a union of 7 subqueries with the results processed within the PHP code; surely it would be quicker to just get the “normal” events, and do the processing of the “repeating” events within PHP extending the work already done on these events. [i.e. my 60+ queries have become 400+ database queries]

    2) Looking at elsewhere at the code, I can see you are basically using “grab_events” to determine whether there is an event on a specific day, again processing the list of events over a period once will speed up these routines.

    3) There are a number of routines called multiple times with the same calculations being performed each time, If the calendar plugin was encapsulated as a class, this would enable the results to be cached as local variables within the plugin to improve performance.

    4) I notice elsewhere you have mentioned in response to concerns on performance that you have imposed limits on the numbers of days the plugin would look out, addressing point (1) above would provide a solution to these concerns.

    Thoughts and comments on these issues would be welcome as I really like the plugin’s functionality and ease of use, but the performance is really causing me problems.

Viewing 1 replies (of 1 total)
  • Plugin Author Kieran O’Shea

    (@kieranoshea)

    Many thanks for the detailed analysis here. Many of the issues you’ve highlighted I’ve been aware of for some time; the plugin is old and although supported in the latest versions of WordPress and has received some updates (namely on request and for security related concerns), it can certainly be said that a solid refactor with a focus on performance is required.

    I’d like to say that I’ll get started on this straight away, but having recently moved house with all of the upheaval that entails, I’m finding very little time to spend on projects outside my day job. Having said that, I can certainly see myself getting round to improving this plugin before the end of the year.

    In terms of what I planned on doing, broadly what you have suggested is about the size of it;

    • Retrieving all the events once (filtering those non-recurring items that have passed)
    • Running PHP logic with date parameters over these for finding events on days
    • Removing restrictions surrounding look ups into the future
    • More closely aligning the data captured with the iCalendar format to permit extensions in this area; you’ll likely have noticed that an iCal feed is now provided in the most recent version although it’s very basic
Viewing 1 replies (of 1 total)
  • The topic ‘Poor Performance’ is closed to new replies.