| Summary: | Statistic plugin takes ages to load | ||
|---|---|---|---|
| Product: | [Unmaintained] kopete | Reporter: | Matteo Croce <rootkit85> |
| Component: | Statistics plugin | Assignee: | Kopete Developers <kopete-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | berkessels, opensource, pookey, tobias.rausch |
| Priority: | NOR | ||
| Version: | 0.11 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Matteo Croce
2006-01-04 23:18:00 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. 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. 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. *** Bug 125024 has been marked as a duplicate of this bug. *** 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. I consider this a bug, there should be something to configure expiring things from the database. consider re-opening ? "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? 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 :) *** Bug 138212 has been marked as a duplicate of this bug. *** Reopening, this is still a problem *** This bug has been marked as a duplicate of 117989 *** |