498968 - Create a new, faster storage "storage2" provider

Status: NEW

(Calendar :: Provider: Local Storage, defect)

Description

[Philipp Kewisch [:Fallen][📱📆]]

There are a few things we can do to improve performance. We have referenced these suggestions as the new "storage2" provider, and I have done a small amount of work on it, but nothing related to recurring events yet.

* We can do it similar to other applications and pre-expand recurring items for a certain timeframe. This will make accessing recurring items i.e +- 1 year from the current day fast, and anything else as slow as it is now.

* We can calculate effective series start and end dates to exclude processing of recurrence rules that definitely don't fall into the range. For example, if you have a recurring event that starts 5 years ago and has an UNTIL part with a date from last year, you don't need to process this event when the range is the current month.

* We can do more complex calculations for certain, common rules. For example Birthdays are yearly on the same day. Instead of doing the usual processing of applying the rule, we may be able to directly check if the day is in the given range (without checking the year).

This can be done in multiple steps, or maybe even as a student project. Please contact me if you would like to work on this so I can send you my work in progress.

Comment 1

[Philipp Kewisch [:Fallen][📱📆]]

Oh yes, storage2 was also especially about saving the calendar data of the event as a blob of ICS instead of saving each field into different database columns, to avoid the need for setting each field extra. This also reduces the complexity since we don't need to update the storage provider for each feature. Some fields (i.e start/end dates) can be extracted and saved in a column, so we can index these columns for faster access.

Comment 2

[Philipp Kewisch [:Fallen][📱📆]]

As noted in bug 501689, it might also help to make storage2 asynchronous.

Comment 3

[Philipp Kewisch [:Fallen][📱📆]]

While it is nice to make storage faster, I think the current state is sufficient for an 1.0 release. As mvl has noted often, the real performance issues are likely in the views instead.

Comment 4

[Shriram (irc: Mavericks)]

(In reply to comment #3)
> While it is nice to make storage faster, I think the current state is
> sufficient for an 1.0 release. As mvl has noted often, the real performance
> issues are likely in the views instead.
Is there a workaround /if not a solution for views?

Comment 5

[Philipp Kewisch [:Fallen][📱📆]]

There are a few bugs (currently) also on the blocking list that should improve the views issue: bug 424808, bug 501302.