Optimisation patch explained

The three parts of optimisation (dated April 27) are aimed at solving performance problem that django-schedule still has. When there are more events and occurrences, the problem becomes rather serious – after adding several one-time and recurring events the total time of processing request for a year calendar on my PC neared 1 minute (!).

Part 1:

This is a pendant to the commit done by Tony on April 10 – initialising a Period with an occurrence_pool. The problem was that in most cases a Period is first initialised without occurrence_pool, so if we keep passing occurrence_pool we are passing None all the time. Hence a change – so that in get_months, get_weeks etc we pass a Period’s occurrences to its child periods. This improves performance by nearly 90%.

Part 2::

If we calculated occurrences for period once, we can cache it for subsequent calls, so that we don’t need to iterate through a potentially long list of occurrences in a pool only to find out there is no match for the current period.

Part 3::

The month_table tag got only a date as an argument, and had to instantiate Month object again (and without a pool), which was redundant becuase when rendering a page we already have months. The only different place was three-month table where we need to instantiate previous and next month, so there is an additional shift argument. (this patch also removes deprecated uname argument which is not used since the decoupling was done).

Part 4::

This template checks two conditions to see if it should render detail section of a day cell; by checking a simpler condition first we eliminate lots of redundant calls to has_occurrences.

All this together reduced response time for year calendar from 52 seconds to less then 1.1 sec.