[PATCH] kdirlister (Re: How can we improve perceived response time?)

[Waldo Bastian]

On Sunday 24 November 2002 14:05, Waldo Bastian wrote:
> On Sunday 24 November 2002 01:39, Roger Larsson wrote:
> > Hard data:
> > * $HOME directory
> > 	I get 224 opens inside my home directory, 192 are not sub ~/{.kde,.qt}
> > 	When konqueror is started all files in my directory are opened -
> > preview? and .directory of most directories are opened too - also
> > preview?
>
> Mimetype detection I think. Preview is handled by the io-slave, so that
> will cause additional file-IO that doesn't show up in a strace of the
> konqueror process.
>
> I do notice that it determines the mime-types of hidden files but that it
> doesn't show those files. It could save some time by not determining the
> mimetypes of those files I would think.
>
> Not sure how difficult that will be to implement since I assume the
> filtering of hidden dirs happens on a different level than the mimetype
> detection.

That wasn't so hard. See attached patch. It reduces the number of files opened 
on startup from 329 to 297 for me (by not opening hidden files in my home-dir 
to determine their mimetype).

For reference, I have 36 hidden files, 14 normal files, 9 hidden dirs and 15 
normal dirs in $HOME.

What is remarkable is that I orignally tried the following patch
--- kdirlister.cpp      2002/11/12 20:41:57     1.155
+++ kdirlister.cpp      2002/11/24 14:20:40
@@ -1812,6 +1812,8 @@
 bool KDirLister::matchesMimeFilter( const KFileItem *item ) const
 {
   Q_ASSERT( item );
+  if (d->mimeFilter.isEmpty() && d->mimeExcludeFilter.isEmpty())
+     return true;
   return matchesMimeFilter( item->mimetype() );
 }

Which delays the mimetype detection till somewhat later for all files, and 
that made things actually slower. No idea why.

Cheers,
Waldo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdirlister.patch
Type: text/x-diff
Size: 637 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20021124/8ccdcd21/attachment.patch>