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