Open Bug 780992 Opened 13 years ago Updated 2 years ago

Rewrite ICS provider to use storage cache only

Categories

(Calendar :: Provider: ICS/WebDAV, defect)

defect

Tracking

(Not tracked)

People

(Reporter: Fallen, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf)

The current ICS provider uses a memory cache and if the cache checkbox is enabled then in addition also the storage cache. One is enough. We should rewrite it to use the storage cache only.
Please do not do this or provide a way to disable storage cache. I have many ics calendars that are stored on local disc. If I enable storage cache on them in current Lightning builds the calendars get much slower.
Obviously if the rewrite degrades performance by such lengths, then it shouldn't be pushed before those issues are resolved. I want to move to making the cache the default, but not at all costs! How is the performance if you import the ICS calendars' data into a storage calendar and disable the ics calendars?
Priority: -- → P2
Priority: P2 → --
(In reply to Philipp Kewisch [:Fallen] from comment #2) > How is the performance if you import the ICS calendars' data into a storage > calendar and disable the ics calendars?
Flags: needinfo?(ssitter)
Keywords: perf
Importing into storage calendar is not an option because the calendars are shared between different systems and therefore have to remain as ics files. I hope I get around to repeat tests soon, maybe situation improved since 2012.
Stefan, when testing maybe you could also apply the patch from bug 501689. I hope the performance improvements made there will also help with cached ICS calendars. The test failures there are mostly because of not adapted unit tests. Thanks for looking into this again!
Depends on: 501689
Stefan? (In reply to Philipp Kewisch [:Fallen] from comment #5) > Stefan, when testing maybe you could also apply the patch from bug 501689. I > hope the performance improvements made there will also help with cached ICS > calendars. The test failures there are mostly because of not adapted unit > tests. Thanks for looking into this again!
Flags: needinfo?(ssitter)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.