[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Disk usage optimizations
From:       "Gary L. Greene Jr." <greeneg () arklinux ! org>
Date:       2005-02-22 18:46:27
Message-ID: 200502221346.33723.greeneg () arklinux ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 22 February 2005 1:28 pm, Mikolaj Machowski wrote:
> Hello,
>
> In last years KDE developers concentrated on CPU and memory
> optimizations with spectacular results. Much kudos to them!
>
> One thing was left back. KDE is 'constructed' from many small
> configuration files - .desktop and .ui files. They give unparelled
> flexibility and power for users. Unfortunately this have one major
> drawback - each time very popular actions are performed many directories
> and even more files have to be scanned to create menus, context menus,
> open file dialogs.
>
> When performing in background actions like: compilation, graphic
> operations on big files, copying of big and many files, scanning has
> take much time. Especially painful it is for opening or saving files
> when dialog takes few seconds to draw contents of $HOME dir; also
> opening of K-Menu can last some time.
>
> My proposition (not coder but active user):
> create binary (pre-compiled) representations for most popular
> destinations and/or GUI elements.
>
> For example main K-Menu very rarely is changed manually, all changes
> from kmenuedit can be introduced when applying changes from editor
> and then precompiled.
>
> The same for main context menu, submenus are
> differement matter but main part is relatively stable. Of course there
> are variations depending on context but all of them change its contents
> very rarely.
>
> Slightly different thing is for $HOME or other start dir of Open/Save
> dialog. Changes there are much more probable. So maybe open binary image
> of dir compare in background real situation and update dialog contents.
> That should not create many problems because in big majority of cases user
> will go for something which already exists and not relatively new
> elements. In KDE apps (kdelibs?) could be builtin calls to update binary
> images for some events.
>
> I understand this is issue for 3.5 or even 4.0 but disk usage
> optimisations shouldn't be overlooked.
>
> m.

That's what ksyscoca is for.

-- 
Gary L. Greene, Jr.
Sent from uriel
 13:45:50 up 8 days, 21:56,  4 users,  load average: 1.06, 1.09, 1.08
 
============================================================
Developer for the Ark Linux Project
 check out http://www.arklinux.org/ for more info.
 Also http://www.csis.gvsu.edu/~greeneg/
EMAIL : greeneg@arklinux.com
============================================================
 

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]