Bug 119529 - Statistic plugin takes ages to load
Summary: Statistic plugin takes ages to load
Status: RESOLVED DUPLICATE of bug 117989
Alias: None
Product: kopete
Classification: Applications
Component: Statistics plugin (show other bugs)
Version: 0.11
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Kopete Developers
URL:
Keywords:
: 125024 138212 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-01-04 23:17 UTC by Matteo Croce
Modified: 2008-01-24 04:21 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matteo Croce 2006-01-04 23:18:00 UTC
Version:           0.11 (using KDE 3.5.0, Debian Package 4:3.5.0-1 (testing/unstable))
Compiler:          Target: x86_64-linux-gnu
OS:                Linux (x86_64) release 2.6.14

The statistics plugin takes *ages* to start.
It takes 1m2.744s to start and ~37 secs to quit.
my system is not so slow:

Athlon64 X2 4400+, 1GB RAM, HD 250GB SATA2.

Disabling that plugin will fix this, so i'm sure that it's the plugin.

Cheers,
Matteo Croce
Comment 1 Matt Rogers 2006-01-05 00:11:18 UTC
The amount of time it takes to load is a function of how many contacts
you have in your contact list and the amount of data that's been
collected for those contacts. So yes, the statistics plugin will
eventually take a long time after it's been used in any case.
Comment 2 Matt Rogers 2006-01-13 02:33:23 UTC
I don't see this as a bug. As the database the statistics plugins stores its information it'll get bigger and take longer to load.
Comment 3 Ber Kessels 2006-03-18 10:26:44 UTC
When one uses kopete for a lot of contact, and on IRC, the logs grow immense. 
It makes kopete load time increase to about 20 (!) seconds on an average >2GHz processor. 
During tha time the disk is hogged, so the system locks up almost completely. 

I consider this a bug. 

Amarok (to name an example) has 'logs' and a database too, but does not need to load it *before* all the rest. This approach: load history 'on-the-fly' or 'load-history-in-the-background' is not too hard to implement IMO, yet it will solve most of these issues.
Conversation (irc app) logs its history too, but has no delay, nor any 'visible' delay. 
Comment 4 Brian Smith 2006-04-06 09:31:46 UTC
*** Bug 125024 has been marked as a duplicate of this bug. ***
Comment 5 Bram Schoenmakers 2006-04-27 22:34:54 UTC
I'm sure there will be plenty of redundant information in the database.
Think of stats of people which are not in your contactlist anymore. As far as I know, this is not deleted from the database.
It should be possible to clean up the database, for example removing contacts and data gathered >1 year ago.
Comment 6 Ian P. Christian 2006-08-25 20:36:13 UTC
I consider this a bug, there should be something to configure expiring things from the database.

consider re-opening ?
Comment 7 Mathieu Jobin 2006-08-26 03:55:10 UTC
"expiring things" ? disregaring old data to reduce database size is not what I call a speed improovement.

or did I miss-understood what you meant to say?
Comment 8 Ian P. Christian 2006-08-26 09:48:38 UTC
nope, you didn't misunderstand at all - I personally would be happy with a 'automatically delete data older then' option with a drop down a '1 month', '3 months' etc.

sure, it would be better to optimise the database... but, I'm happy with a quick fix :)
Comment 9 Jan Ritzerfeld 2006-12-01 16:41:27 UTC
*** Bug 138212 has been marked as a duplicate of this bug. ***
Comment 10 Charles Connell 2008-01-24 04:20:43 UTC
Reopening, this is still a problem
Comment 11 Charles Connell 2008-01-24 04:21:28 UTC

*** This bug has been marked as a duplicate of 117989 ***