After finding there’s a performance regression in sqlite I finally found some time to pinpoint what exactly regressed. While I’m not 100% certain that the query I used for this is exactly the one Quassel uses, it is very likely.
It turns out in newer versions of sqlite the query planner wasn’t using an index present in Quassel’s database for sorting but instead used manual sort. And this slowed it down noticeably. Since reporting this issue it’s been fixed and will be included in the next release versioned as 3.8.7. When it reaches Utopic I can unlock sqlite from upgrading on my machine :)
I recently upgraded from Kubuntu 13.10 to 14.04. It generally went smoothly. I only had an issue with Thunderbird crashing into bug 985986 and then Quassel starting up extremely slowly like 4-6 minutes until I can see and send messages.
I’ve been using Quassel for years and my database (sqlite) had grown to 750M. Since I was told on #quassel that sqlite doesn’t perform well with that big databases I assumed that was it. I made a copy of my database and deleted older messages (in backlog table) from one and newer ones from another. This way I have an archive if I want some information out of it but it isn’t available as scrollback all the time when I don’t need it. I then tried using Quassel again with a database less than 300M. It was still slow (around 30s) to startup.
Today I tried downgrading quassel from 0.10.0 to 0.9.1 that I used in 13.10. That did not help, Quassel remained slow. I then tried downgrading sqlite3 (libsqlite3-0 and sqlite3 packages) from 3.8.2 to 3.7.17. That sped up Quassel to normal few seconds it takes to fetch messages from ZNC. I then upgraded Quassel to 0.10 again and it remained fast. I also tried upgrading sqlite to Utopic packages with 3.8.5 but that was slow as well.
So it seems that for the queries Quassel executes on startup (of which I have no idea what they are) there’s been a regression in sqlite3 between versions 3.7.17 and 3.8.2. Using sqlite3 from Saucy works as a workaround.