To clarify, out of the box on krillin with no calendar sync even enabled, evolution-calendar-factory uses 32MB which is the 4th highest process in memory usage. This is with an empty database of no calendar events or alarms.
I'm assuming evolution-calendar-factory gets loaded by indicator-datetime initially such that the indicator can show calendar events.
If you have a large database of calendar entries (i.e. after you've done a google calendar sync), as Pat reported this process can grow to well over 100MB. It seems to have no upper bound, and since the evolution backend for calendar is simply a flat file of type .ics, e-c-f appears to load the entire file into memory.
e-c-f really needs a sqlite backend or something such that it can manage it more efficiently. Someone needs to investigate what can be done in the short term reduce the memory usage if possible.
To clarify, out of the box on krillin with no calendar sync even enabled, evolution- calendar- factory uses 32MB which is the 4th highest process in memory usage. This is with an empty database of no calendar events or alarms.
I'm assuming evolution- calendar- factory gets loaded by indicator-datetime initially such that the indicator can show calendar events.
If you have a large database of calendar entries (i.e. after you've done a google calendar sync), as Pat reported this process can grow to well over 100MB. It seems to have no upper bound, and since the evolution backend for calendar is simply a flat file of type .ics, e-c-f appears to load the entire file into memory.
e-c-f really needs a sqlite backend or something such that it can manage it more efficiently. Someone needs to investigate what can be done in the short term reduce the memory usage if possible.