Re: kdeinit hack for faster apps startup and more shared memory

"Dr. Juergen Pfennig" <[email protected]>
Newsgroups gmane.comp.kde.devel.optimize
Organization Softwareentwicklung
Message-ID <[email protected]>
On Wednesday 30 June 2004 17:58, Lubos Lunak wrote:

>  KDE3.2 got quite good reputation for being faster than KDE3.1. And since
> (AFAIK) there haven't been any noticeable optimizations for KDE3.3, I'd
> like to get in 3.3 at least the attached kdeinit hack. Done by Michael
> Matz, tested by Coolo, fixed by me :).

I remember well that Linux once has had a reputation for starting much faster 
than windows. Good for the windows users is that Win 2003 now starts 
DRAMATICALLY faster than Linux + KDE. Try it! This situation is completely 
UNACCEPTABLE. We have to improve (Linux) and KDE. Questions:

(1) How much delay is contributed by searching/loading icons?

What about making an Icon-Inventory (or a catalog). This would store the 
result of an initial icon search and would only be updated incrementally when 
a directory that was searched before has changed after the search. Or is it 
already handled that way? Remember: Windows uses a "shell icon cache" - but 
that did not work well at the beginning. Maybe we can have something better.

(2) What about the config files?

Eventually we could create a mechanism that kdeinit pre-reads at least some 
typical config files and passes the contents to the new app. Or is it already 
handled that way? In a another thread a while ago someone came up with the 
idea to write a kio-slave for handling all config files: background was 
something like roaming profile support with a local copy of the profile in 
the case that the server is offline or not reachable.

A Suggestion concerning kdestart:

(3) kdestart tries to change the classic X-Server background as early as 
possible to get rid of the ugly pepper-and-salt default pattern. But nowadays 
it is more convenient to start X with -br (black background) and not trying 
to change the background in kdestart. At least VNC sessions produce less 
flicker this way.

Jürgen
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.