[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: [Fwd: Bundles, Thoughts about files]
From: "Jos Poortvliet" <jos () mijnkamer ! nl>
Date: 2007-08-09 10:04:54
Message-ID: 5c77e14b0708090304x66839171u2b1ef02398c2ab08 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
[Attachment #4 (text/plain)]
On 8/9/07, James Richard Tyrer <tyrerj@acm.org> wrote:
>
> Lubos Lunak wrote:
> > Dne středa 08 srpen 2007 14:23 Bernd Brandstetter napsal(a):
> <SNIP>
> >> One the other hand there are the bookmarks where at least some users
> would
> >> benefit if they were accessible via the file system. These however are
> >> stored in a container file and thus, only accessible via some tool.
> >>
> >> Actually, I don't care that much if this will be changed or not, I just
> >> cannot quite agree with the argument about possible filesystem
> performance
> >> penalties because in other places this does not seem to be an issue -
> or
> >> nobody seems to care about it.
> >
> > http://code.google.com/soc/2007/kde/appinfo.html?csaid=1EF6392A4C8AEADD
> >
> This appears to be a good idea. However, it is very likely that this
> file would probably be in swap so it would still take a disk access to
> load an icon. The performance improvement is going to come from knowing
> exactly where to read the icon. So, I have to ask, since, IIUC, the
> information regarding which icon to use is currently cached in ksyscoa,
> is this going to make a large improvement in performance unless the
> system has a lot of memory.
Can't they just lock the file to ensure it doesn't go into swap? Besides,
it's also about sharing the icons between apps, if I understood it
correctly. Which saves mem, so there's room for the cache ;-)
And reading the cache from disk is of course faster than reading the
seperate icon files, yes.
--
> JRT
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>
[Attachment #5 (text/html)]
On 8/9/07, <b class="gmail_sendername">James Richard Tyrer</b> <<a \
href="mailto:tyrerj@acm.org">tyrerj@acm.org</a>> wrote:<div><span \
class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px \
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Lubos Lunak \
wrote:<br>> Dne středa 08 srpen 2007 14:23 Bernd Brandstetter \
napsal(a):<br><SNIP><br>>> One the other hand there are the bookmarks \
where at least some users would<br>>> benefit if they were accessible via the \
file system. These however are <br>>> stored in a container file and thus, only \
accessible via some tool.<br>>><br>>> Actually, I don't care that \
much if this will be changed or not, I just<br>>> cannot quite agree with the \
argument about possible filesystem performance <br>>> penalties because in \
other places this does not seem to be an issue - or<br>>> nobody seems to care \
about it.<br>><br>> <a \
href="http://code.google.com/soc/2007/kde/appinfo.html?csaid=1EF6392A4C8AEADD"> \
http://code.google.com/soc/2007/kde/appinfo.html?csaid=1EF6392A4C8AEADD</a><br>><br>This \
appears to be a good idea. However, it is very likely that this<br>file \
would probably be in swap so it would still take a disk access to <br>load an \
icon. The performance improvement is going to come from knowing<br>exactly \
where to read the icon. So, I have to ask, since, IIUC, the<br>information \
regarding which icon to use is currently cached in ksyscoa, <br>is this going to make \
a large improvement in performance unless the<br>system has a lot of \
memory.</blockquote><div><br>Can't they just lock the file to ensure it \
doesn't go into swap? Besides, it's also about sharing the icons between \
apps, if I understood it correctly. Which saves mem, so there's room for the \
cache ;-) <br><br>And reading the cache from disk is of course faster than reading \
the seperate icon files, yes.<br></div><br><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;">
--<br>JRT<br><br>>> Visit <a \
href="http://mail.kde.org/mailman/listinfo/kde-devel#unsub">http://mail.kde.org/mailman/listinfo/kde-devel#unsub</a> \
to unsubscribe <<<br></blockquote></div><br>
>> 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