Tue 2008/Mar/18

• Ross posted about people wanting to write replacements for evolution-data-server, and I agree with him that doing so is a mistake.

  When we originally wrote Evolution, a lot of backend-ish things were left in a "we'll fix this later" state. It was more important to have a simple, working backend and a totally awesome frontend GUI, than to have a super-optimized backend and a shitty GUI.

  The code in e-d-s is a good example of something that could get a lot of easy love if people simply took the time to understand what is wrong with it in the first place.

  Some things that could be done to e-d-s reasonably easily:

  • Evolution-data-server has a reputation for becoming a very big process with a small resident size. On my box, pmap(1) says that e-d-s has a 14 MB heap with 12 MB resident. That's tiny by today's heap standards. However, there are 8 or so threads with an 8 MB stack each, which is of course not even used. An easy cure for people's fears of the total VM size would be to fix the size of the stack in the threads.

  • Avoid scanning the entire list of calendar events when someone makes a query. The most fundamental API in the e-d-s calendar is, "give me all the events that fall within $range_of_timestamps". For example, the Evolution calendar's week view will say, "give me all the events for the current week". E-d-s then goes and looks at all the events it knows about, sees if they intersect the specified time range (generating recurrences if needed), and builds a list of results. This makes each query run in O(num_events) time — nobody cleans up their old events, so this degrades pretty quickly over time!

    There are various ways to fix this. You could read the calendar.ics file into memory, but instead of storing a dumb linked list of events, you could store an interval tree based on the time range for events. An event that occurs only once has a range of [t1, t1 + duration]. An recurring event that repeats indefinitely has a range of [t1, ∞). If you are careful with the way you organize your data, you can avoid even looking at the memory pages for the event info, and just look at the pages where the interval tree is stored.

  • My calendar.ics file is 700 KB, and addressbook.db is 400 kb. So, why does e-d-s have a resident heap of 12 MB? "Use a database for the calendar" is total overkill, and less reliable than a simple text file. Someone needs to actually look at how much space e-d-s uses in memory for its various data structures, and then see why they become so big when loaded.

  When your bathroom becomes kind of dirty and gross, do you demolish it and build a new bathroom? No, you clean it up. It's a shame that software seems so easy to demolish and rebuild.

Syndicated 2008-03-18 14:38:00 from Federico Mena-Quintero - Activity Log