Bug 332497 - Option for preload contactlist module and keep in memory for quick open-close contact list window
Summary: Option for preload contactlist module and keep in memory for quick open-close...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: telepathy
Classification: Unmaintained
Component: contactlist (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: Future
Assignee: Telepathy Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-24 10:58 UTC by Murz
Modified: 2024-09-18 18:14 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:
mklapetek: Decision-Required+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Murz 2014-03-24 10:58:21 UTC
When user click on "Instant messaging presence" widget, it loads ktp-contactlist app, that spend not short time (about 3-10 seconds). And when user close contact list and after some time opens it again, he must wait same 3-10 seconds again.

I understand that this time is needed for initialize and load ktp-contactlist application, but this is not comfortable for users, because they can open-close contact list 100 times per day.

If system is busy and computer is not quick, time 3-10 seconds can be increased up to 30 seconds, so users clicks on "Instant messaging presence" widget one time, wait some seconds, understand that his fist click not obtained by system and repeat clicks again and again.

Same problem is with kde-telepathy-text-ui - when text ui window is closed and I receive new message, I must wait 3-10 seconds when kde-telepathy-text-ui loads.

Before I use Kopete, Vacuum, PSI and all other available messengers and they don't have this problem, they loads all needed modules only once on startup and after this all works quickly.

For solve this problem will be good to add option "Keep ktp-contactlist in memory" or "Preload ktp-contactlist at startup and keep always in memory" in kde-telepathy settings, and same options for kde-telepathy-text-ui and other modules.

What do you think about this problem and proposed solution?

Reproducible: Always
Comment 1 Martin Klapetek 2014-03-24 11:05:07 UTC
I remember we had couple wishes like this, but then we tuned the models and everything and contact list was generally starting very fast (less than 2 secs here) so we didn't bother.

The code side is then actually quite easy for contact list, basically just replacing close() with hide() and little bit of glue at places.

I'm not too sold on having this as an option somewhere in the settings, but generally I'm not against this idea. I'll let others comment too.
Comment 2 David Edmundson 2014-03-24 11:45:35 UTC
I consider that a workaround.

The benefit of our approach is considerably less memory usage when you don't have the list open. I don't want to throw away one of our best features because of a technical issue, especially for one that I don't see.

3-10 seconds seems ridiculously high.
can you run 
"time ktp-contactlist --nofork"

Where is the delay? Before you see the window? Seeing the contacts load? 
Also could you confirm your version number. There's an option in the menu "About Contact List"
Comment 3 Martin Klapetek 2014-03-24 11:55:07 UTC
Plus if the list would be running constantly, it would cause way more CPU wakeups to keep all the contacts up to date with the backend (their presence etc; the backends are running and doing this anyway, but with the contact list opened and hidden the wakeups would just multiply).
Comment 4 David Edmundson 2014-04-02 16:48:52 UTC
I am waiting for my information requested in comment #2
Comment 5 Murz 2014-04-02 18:47:54 UTC
Version of kde-telepathy is 0.7.80.

Here http://pastebin.com/raw.php?i=54n4cCs9 is output of command:
$ time ktp-contactlist --nofork
- run first time after boot, time from command to contact list showed is about 7 seconds.

Here is output when it is closed:
real    28m15.718s
user    0m2.828s
sys     0m0.350s



Here is second run of kde-telepathy:
-------------------------------------------------------
$ time ktp-contactlist --nofork
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
ktp-contactlist(31171) KPixmapSequence::Private::loadSequence: Invalid framesize. 
tp-qt 0.9.3 WARN: Error parsing config file for connection manager "haze" - introspecting  
tp-qt 0.9.3 WARN: Error parsing config file for connection manager "haze" - introspecting  
ktp-contactlist(31171) KPixmapSequence::Private::loadSequence: Invalid framesize. 
ktp-contactlist(31171) KPixmapSequence::Private::loadSequence: Invalid framesize. 
ktp-contactlist(31171) KPixmapSequence::Private::loadSequence: Invalid framesize. 
tp-qt4-tpl DEBUG:  static Tpl::Utils* Tpl::Utils::instance()  :  Created Utils instance 

real    0m6.530s
user    0m1.132s
sys     0m0.271s
-------------------------------------------------------
Time is about 1-2 seconds.

Here is after some time of work with system after close contactlist:
-------------------------------------------------------
$ time ktp-contactlist --nofork
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
ktp-contactlist(32460) KPixmapSequence::Private::loadSequence: Invalid framesize. 
tp-qt 0.9.3 WARN: Error parsing config file for connection manager "haze" - introspecting  
tp-qt 0.9.3 WARN: Error parsing config file for connection manager "haze" - introspecting  
ktp-contactlist(32460) KPixmapSequence::Private::loadSequence: Invalid framesize. 
ktp-contactlist(32460) KPixmapSequence::Private::loadSequence: Invalid framesize. 
ktp-contactlist(32460) KPixmapSequence::Private::loadSequence: Invalid framesize. 
tp-qt4-tpl DEBUG:  static Tpl::Utils* Tpl::Utils::instance()  :  Created Utils instance 
Bus::open: Can not get ibus-daemon's address. 
IBusInputContext::createInputContext: no connection to ibus-daemon 
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 20 (X_GetProperty)
  Resource id:  0x4400085

real    0m11.533s
user    0m3.332s
sys     0m0.560s
-------------------------------------------------------
Time is about 3-4 seconds.

But this is on quick computer - Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 4 GB RAM, SSD Drive.

I will repeat this test on my work computer and report here. My work computer boots from network (pxe boot on 1gbit network via nfs), so 3-4 seconds here will be 10-15 seconds on work computer.
Comment 6 Murz 2014-04-02 18:49:33 UTC
> it would cause way more CPU wakeups to keep all the contacts up to date with the backend

I understand this, so optionally enable keep it in memory will be good solution, users that want to quick open contactlist each time - will enable this, but other will use default settings with this option enabled.
Comment 7 Murz 2014-04-03 05:24:31 UTC
Here is results on PXE netboot computer:
First start
real    0m23.958s
user    0m1.368s
sys     0m1.326s
Delay is about 10-15 seconds

Second-starts:
real    0m4.122s
user    0m0.424s
sys     0m0.366s
Delay is about 3 seconds

real    0m4.189s
user    0m0.405s
sys     0m0.351s
Delay is about 3 seconds

real    0m5.836s
user    0m0.438s
sys     0m0.346s
Delay is about 5 seconds

Delay more than one second is confuse users, so user want to click on icon to show contactlist again and again :(
Comment 8 Murz 2014-04-07 10:48:10 UTC
I install clean Kubuntu 14.04 and KDE-Telepathy 0.8 release, configure 3 jabber accounts. Computer is not slow: Intel(R) Core(TM) i3-2105 CPU @ 3.10GHz, SSD drive, 8 Gb RAM

Here is load time for contact-list (immediatly after close):
real    0m4.060s
user    0m2.400s
sys     0m0.098s

Time to contacts showed is about 5-6 seconds - at first 3-4 seconds in display I see only window with empty contact list, after this contacts are loaded line-by-line in 2-3 seconds.
Comment 9 David Edmundson 2014-04-07 11:01:19 UTC
I've added this as an agenda point on the sprint wiki.
Comment 10 Renato Atilio 2014-04-23 00:50:35 UTC
I don't know if a new bug should be entered - or if I am missing something, but what I find annoying about the current behavior is that I've some one-contact groups that are always shown collapsed (I don't know why, exactly). Then I expand them, close the contacts list, and when I re-open it, these groups are collapsed again.
Comment 11 Martin Klapetek 2014-04-23 11:22:53 UTC
Unrelated really, but bug #325506; fixed.
Comment 12 David Edmundson 2014-04-25 09:35:33 UTC
Could you please re-test the timings after ktp 0.8.1 (release this weekend)
we have made some huge improvements.
Comment 13 Murz 2014-05-04 07:50:35 UTC
I wait for updated packages into Ubuntu, but at now there are no updates in repository. Also in Daily Telepathy KDE PPA there are no packages for Ubuntu 14.04:
https://launchpad.net/~telepathy-kde/+archive/daily-builds?field.series_filter=trusty

So I can't do tests and report results at now, will wait for updates.
Comment 14 Murz 2014-05-21 10:26:40 UTC
I updated today to version 0.8.1 and here is test results on SSD drive:

First open after boot - about 4 :

$ time ktp-contactlist --nofork 
real    0m4.222s
user    0m0.806s
sys     0m0.143s
on the eye - time to see contacts - 2-3 seconds

Second run:
real    0m5.034s
user    0m1.015s
sys     0m0.147s
on the eye - time to see contacts - 1-2 seconds

Click on the icon in plasma panel: 
on the eye - time to see contacts - 2-4 seconds



Same test on this computer with nfs mounted root and home folders (1 gbit LAN):

$ time ktp-contactlist --nofork 
real    0m8.644s
user    0m0.685s
sys     0m0.518s
on the eye - time to see contacts - 5-6 seconds

Second run:
real    0m8.050s
user    0m0.627s
sys     0m0.303s
on the eye - time to see contacts - 2-4 seconds

Click on the icon in plasma panel: 
on the eye - time to see contacts - 3-7 seconds
Comment 15 Martin Klapetek 2014-05-21 11:27:11 UTC
Just to confirm - which libkpeople version do you have now?
Comment 16 Murz 2014-05-21 11:36:09 UTC
libkpeople3 - version 0.2.2-0ubuntu0.1

I think that large delay in nfs mount is because of disk operations, needed for load contactlist window from disk (read config files, libraries, etc), so I don't think that we can solve this problem without caching all data and libs, needed for contactlist window, in RAM. And for other users, that don't want waste RAM via this data, make this optionally.

Easiest way for do this is add selection for users like this:
Action on "Close" button in contactlist window:
- Full unload contactlist application (minimize memory and cpu usage)
- Hide contactlist window only, and keep application in memory (quick reopen contactlist)

And with "keep in memory" we can only hide contactlist window from interface and keep all other working in background (maybe with lower 'nice').
Comment 17 Martin Klapetek 2014-05-21 11:54:17 UTC
Personally I would like to avoid adding options like this, it's useful for about 5% of users. Maybe a command line option/config file option could work...

Thanks for all the input, I'll give it some thought.
Comment 18 Thomas Van Parys 2014-06-16 12:27:51 UTC
I just wanted to concur with this complaint. It's what made me (temporarily, I'd prefer to use Telepathy) switch back to Pidgin.

On a recent and powerful laptop, with two or three accounts (Facebook, GChat, sometimes Jabber) and a modest amount of contacts, clicking the widget in the tray brings up an empty contact list immediately. 2s later, the status switches to "Available" and then only after another 3 or 4s, the contacts show up. This is quite long for just taking a quick peek who's online.
The exact same configuration in Pidgin brings up a populated contact list instantaneously.

This behaviour is with 0.8.0. Waiting for package updates (Fedora) to give the new release a try.
Comment 19 Martin Klapetek 2014-06-16 14:30:50 UTC
Quoting comment #12:

Could you please re-test the timings after ktp 0.8.1 (release this weekend)
we have made some huge improvements.

...and libkpeople 0.2.2.
Comment 20 Murz 2014-06-23 05:33:24 UTC
I already test version 0.8.1 and the problem is here. The easiest solution will be change action on "Close" button in KDE Telepathy contact window - to hide window (without unloading anything) for hide it from task list in panel, and show it back on icon click.
This is "two strings" in code and solve the problem quickly. If you don't want to add this in options window, please add this as hidden option in configuration rc file.

This maybe quick temporary solution before you solve the problem with slow loading-unloading full contact list, can you do this?
Comment 21 Thomas Van Parys 2014-07-08 13:46:19 UTC
Since the upgrade to 0.8.1 (still libkpeople 0.2.2-1 on Fedora) the performance indeed improved severely. Hiding/showing of the contact list now happens almost instantly again.

Thanks!
Comment 22 Murz 2014-07-08 13:53:03 UTC
I still have problems with slow opening contact list on Ubuntu 14.10 with versions:
libkpeople3                                                 0.2.2-0ubuntu0.1
kde-telepathy                                               0.8.0ubuntu1
kde-telepathy-approver                                      0.8.1-0ubuntu0.1
kde-telepathy-auth-handler                                  0.8.1-0ubuntu0.1
kde-telepathy-call-ui                                       0.8.1-0ubuntu0.1
kde-telepathy-contact-list                                  0.8.1-0ubuntu0.2
kde-telepathy-data                                          0.8.1-0ubuntu0.1
kde-telepathy-declarative                                   0.8.1-0ubuntu0.1
kde-telepathy-desktop-applets                               0.8.1-0ubuntu0.1
kde-telepathy-filetransfer-handler                          0.8.1-0ubuntu0.1
kde-telepathy-integration-module                            0.8.1-0ubuntu0.1
kde-telepathy-minimal                                       0.8.0ubuntu1
kde-telepathy-send-file                                     0.8.1-0ubuntu0.1
kde-telepathy-text-ui                                       0.8.1-0ubuntu0.1

- I didn't see any improvements in showing time from 0.8 version, maybe because kde-telepathy is still at version 0.8?

Same problem with slow opening is with kde-telepathy-text-ui module.
Comment 23 Christoph Cullmann 2024-09-18 18:14:20 UTC
Dear user, unfortunately Telepathy is no longer maintained.

Please migrate to another solution, e.g. for Jabber a possibility is Kaidan, for Matrix a candidate is NeoChat.