KDE-Connect and KDED

[Àlex Fiestas]

On Thursday 06 March 2014 12:22:08 Yuri Samoilenko wrote:
> Hello
> 
> > I don't see why anybody would care on restarting/starting/stopping kde-
> > connect.
> 
> I talking about possibility to start/stop/autostart. How often do you use
> system services in /etc/init.d/ ? I'am using it very rare(once per week),
> but i CAN stop/restart ssh, samba, dedicated virtuaboxes, apache, ntp, bind
> and so on.
For this we can add an option into the kcm, where it will be more discoverable 
btw.
> > It is something build in into your KDE session, if you don't want it just
> > kill
> > it, no?
> > We should use almost no cpu/ram when idle anyway.
> 
> What do you talking about? kdeconnect daemon consumes just about 2.5 mb of
> memory. All other memory(qt/kde libraries) already shared between desktop
> environment. Listening on socket to wait for incoming data/connection is
> not consuming CPU, so CPU usage for kdeconnect when idle is 0.0%.
> ANY plasma/QML applet consumes CPU and memory _much_ more than simple
> daemon that just listen port.
Yeah, we have to add/remove the applet as well when no devices are connected.

> I'am agreed that KDED have little overhead to us, but there is no other
> inretface in KDE environment to control daemons. There is no interface to
> completly DISABLE something, or to temporary stop, except KDED.
> KDE have a simple facility to autostart something
> sytemsettings->administration->autostart but we can't disable or stop
> runned process. Or start it without restarting whole KDE session.
Then let's add an option in our KCM to make things simple and usable.
We did this in BlueDevil and worked quite nice.
> >> Albert: I think it is nice to start kdeconnect on demand (via dbus
> 
> calls). I see the benefits of killing it automatically if there are no
> devices reachable, or none of them is paired, but this causes a problem: we
> wont be discoverable since the process is not there anymore.
> 
> Any dbus service consumes more CPU and memory than simple kdeconnectd
> daemon.
This is incorrect since kdeconnectd is already a dbus service.
> >> Albert: Anyway we have to think a way to use ZERO memory if the user is
> 
> not using kdeconnect at all, because our process now is quite fat.
> 
> How you measured memory consumption related to kdeconnectd? I'am agree that
> plasmoid can consume a lot of memory for QML engine, interpretter, GUI,
> DBUS and other, But how can simple daemon can be fattest than any dbus
> daemon or any other "frameworked" daemon?
> 
> To use ZERO memory user can completly disable kdeconnectd through KDED
> module by just removing checkbox in systemsettings like many other KDE
> services for example touchpad, remote control, nepomuk(!) and other.
The point is that by using the KDED we can use only a few K of private memory 
when no devices are connected.

Remember that only the shared memory is *shared*, the private is not. In the 
case of Qt there is a lot of private memory for things like i18n, l10n, 
settings etc that it won't be shared unless you do some dirty hacks like 
dlopen (like we do in kdeinit).

Depending the Qt/KDE libraries on use the private memory overhead is usually 
from 3 to 9Mb. Let's imagine we have an average of 6, that multiplied by the 
amount of KDED I have right now running, 30 produces a total memory saving of 
180Mb of ram.

Remember that the KDED will only listen for incoming connections, the moment 
we get any we fire up kdeconnectd to handle the situation.

Anyway, I can see how this complicates things way more than what is desirable, 
so I'm going to give it a try and if I can't achieve it on an hour I will drop 
the idea.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20140306/ea8c25a5/attachment.sig>