[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: Improving performance of KDE
From: "David Boosalis" <david.boosalis () gmail ! com>
Date: 2008-07-17 22:32:16
Message-ID: 870c99310807171532s3c8ad90eva111de3a32018f8e () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Yes, but my point is the pixmaps are still read into cache one at a time.
The cache only pays off the second time you access a pixmap, (I believe this
is correct) I am thinking to load all the pixmaps at once into memory.
The trick would be to store all the pixmaps to a virtual file system as I
have done or store them all into one giant file and load that. How we could
do this would require a little thought. Memory is cheap, but disk access
hasn't changed much in ten years or more.
I am just thinking aloud here as doing disk operations really slows down
performance. Duel Core, Quad Core, none of that helps when you are waiting
on the disk that operates a thousand times slower then memory access.
Icons are not the only culprit, *.desktop files, hundreds if not thousands
of them. And plugins that read and parse xml files. We are in an
environment where memory is cheap and fast. Maybe it is time to rethink the
current paradigm for storing and retrieving resources.
.
On Thu, Jul 17, 2008 at 12:07 PM, Aaron J. Seigo <aseigo@kde.org> wrote:
> On Thursday 17 July 2008, David Boosalis wrote:
> > When ever I start KDE (3, or 4) it bothers me to think that each little
> > icon it displays results in a hard drive access.
>
> this is, of course, why we introduced the shared icon cache in kde4 =)
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Trolltech
>
>
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>
>
[Attachment #5 (text/html)]
<div dir="ltr">Yes, but my point is the pixmaps are still read into cache one at a \
time. The cache only pays off the second time you access a pixmap, (I believe \
this is correct) I am thinking to load all the pixmaps at once into \
memory. The trick would be to store all the pixmaps to a virtual file system as \
I have done or store them all into one giant file and load that. How we could \
do this would require a little thought. Memory is cheap, but disk access \
hasn't changed much in ten years or more.<br> <br>I am just thinking aloud here \
as doing disk operations really slows down performance. Duel Core, Quad Core, \
none of that helps when you are waiting on the disk that operates a thousand times \
slower then memory access. <br> <br>Icons are not the only culprit, \
*.desktop files, hundreds if not thousands of them. And plugins that read and \
parse xml files. We are in an environment where memory is cheap and \
fast. Maybe it is time to rethink the current paradigm for storing and \
retrieving resources. <br> <br><br><br>.<br><br><br><br><div \
class="gmail_quote">On Thu, Jul 17, 2008 at 12:07 PM, Aaron J. Seigo <<a \
href="mailto:aseigo@kde.org">aseigo@kde.org</a>> wrote:<br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">On Thursday 17 July 2008, David \
Boosalis wrote:<br> > When ever I start KDE (3, or 4) it bothers me to think \
that each little<br> > icon it displays results in a hard drive access.<br>
<br>
</div>this is, of course, why we introduced the shared icon cache in kde4 =)<br>
<font color="#888888"><br>
--<br>
Aaron J. Seigo<br>
humru othro a kohnu se<br>
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br>
<br>
KDE core developer sponsored by Trolltech<br>
<br>
</font><br><br>
>> Visit <a href="http://mail.kde.org/mailman/listinfo/kde-devel#unsub" \
target="_blank">http://mail.kde.org/mailman/listinfo/kde-devel#unsub</a> to \
unsubscribe <<<br> <br></blockquote></div><br></div>
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic