Re: Reimplementing trivial apps as dcop services
Frans Englich <[email protected]> Mon, 4 Apr 2005 11:37:10 +0000
| Newsgroups | gmane.comp.kde.devel.optimize |
|---|---|
| Message-ID | <[email protected]> |
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