Back from Istanbul and a few updates

Pretty late blog, but really busy. I landed in Bangalore on July 14 8am to attend a 5 day out-door training starting at 10am. Lucky that the timezone difference isn’t very bad, I happened to manage with my training.

Guadec:

  • Nice parties and thanks to all their sponsors and GNOME.
  • Had nice discussions/talks with Michael, jpr, hpj, Miguel, Aaron, Scott and lot of other hackers
  • Announced about the Evolution licensing change
  • Had a couple of talks at GUADEC
  • Nice chats with Muelli, jrb, thomas, philip,  jorgen
  • Attended lots of talks

Post guadec:

  • Stuck in a training till friday on project management training.
  • Merged on-disk summary with trunk and guess what trunk must be broken for few/most cases. We will shape it well.Blame me/sankar if you see lots of warning on compilation, we explicitly added ‘#warnings’ for lots of stuffs to make sure we fix it instead of growing FIXMEs in the code. We ported most of the providers. Didnt do much for imap4 provider. But will do for it also post 2.23.5 which is on Monday. (Sorry fejj, too busy, so we delayed it). Any other camel provider like evolutin-brutus needs to be ported. I had a live demo at guadec on this and I have some graphs which I collected during my demo. I will attach at the end of the blog.

I had a fixed set of data for Evolution, couple of accounts and 2 vfolders which sort of fetches from all these folders. In total 200,000 mails.

Evolution 2.23.4 (before the merge)

before moving to disk summary

Evolution 2.23.5 (after the merge)

After the merge

Sankar already did a post on how it is done. I got these from massif, I know these arent exact but the comparison sort of shows difference/improvements.Evolution sort of releases unused memory over a period of time when you move away from folders and vfolders queries from db and loads counts. So nothing is loaded except what you see. But there are some issues lying around with the sqlite memory cache free, because of which at times it goes 100% cpu on to allocation of memory during sqlite commit. So Im sort of disabling all memory drop thread for 2.23.5 and would get them to shape during 2.23.6 or so. We have added lots of debug and g_assert(0) at few places to capture some important traces/issue so bear with us in 2.23.5 if it crashes more. File all your bugs to bugzilla and add to the tracker bug. All would be fixed and Evo 2.24 would be slim and rock solid.

One Comment

  1. Jeffrey Stedfast
    Posted July 20, 2008 at 5:32 am | Permalink

    Hey, this is pretty amazing work!

    Don’t worry about porting the imap4 provider, I can handle that (tho I may wait until after 2.24 is released).