Reimplementing trivial apps as dcop services

Frans Englich frans.englich at telia.com
Mon Apr 4 13:37:10 CEST 2005


On Sunday 03 April 2005 00:21, Luke Alan Sandell wrote:

> Of course, the actual command-line utilities could be rewritten as shell
> scripts that call 'dcop' based on the command-line arguments passed to
> them. Also, we don't want all these random dcop services sitting around in
> the process list, so they should probably be integrated into kded. I was
> wondering if this all makes sense, and if should I continue with it...

I wonder if the increased complexity is worth the gain. However, the penalty 
is clearly there.

I've recently encountered it with kdom's kxmllint(kdenonbeta/kdom/kxmllint). 
When simply parsing a file, the initial startup takes a couple of seconds, 
but when the relevant code have started to actually run, there's no user 
noticeble difference to xmllint, libxml2's parser utility. xmllint's startup 
time is not perceptable -- it links to a C library or two, compared to KDE's 
heavy framework.

AFAICT, this startup problem is not constrained to the scripting utilities you 
mention, but applies for all KDE applications, more or less. Global 
optimizations are needed -- a certainly well discussed topic.

I have no concrete examples, but it /feels/ overkill and asking for trouble to 
do these optimizations for small scripting utilities.


Cheers,

		Frans


More information about the Kde-optimize mailing list