You are not logged in.

Dear visitor, welcome to If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.


Thursday, April 27th 2006, 2:45pm

[Kopete] Statistics module generates I/O

I just noticed that with the statistics module turned on, Kopete takes much longer to start and quit than without it. According to strace, it generates lots of I/O on the file ~/.kde3.5/share/apps/kopete/kopete_statistics-0.1.db. Although the file is only 3 MB, that usually takes more than ten seconds. Since I'm not going to use the statistics module any more, that doesn't really matter to me, but I'd like to know whether it may be a bug (or rather a bad algorithm) because I would submit it to the bug database in that case.



Posts: 948

Location: Eindhoven

Occupation: Software Engineer

  • Send private message


Thursday, April 27th 2006, 6:07pm

RE: [Kopete] Statistics module generates I/O

Please submit a bug to Bugzilla.

However my statistics are about 4,2 MB, I don't really notice it's really slow. Or maybe I just don't know any better. :)
Bram Schoenmakers
KDE Netherlands (


Thursday, April 27th 2006, 6:47pm

RE: [Kopete] Statistics module generates I/O

It doesn't seem to be considered a bug. Sorry to have taken up your time, I should have looked in the database earlier.



Posts: 105

Location: US

Occupation: Software Engineer

  • Send private message


Thursday, April 27th 2006, 10:37pm

RE: [Kopete] Statistics module generates I/O

the statistics use sqlite as a database backend. As you collect statistics over a large period of time, the size of the database will grow. As the size of the database grows, the amount of IO needed to load the database will grow. Sqlite must be slower than we thought. We've delayed the loading of the database a bit, so starting kopete should be faster with 0.12, but we'll need to use a different solution in the future, i think.