[Kde-pim] mixedmaildir optimization suggestion

Kevin Krammer krammer at kde.org
Fri Sep 21 15:58:50 BST 2012


On Friday, 2012-09-21, Andras Mantia wrote:
> Kevin Krammer wrote:
> > On Thursday, 2012-09-20, Andras Mantia wrote:
> >> The cache itself is not invalidated automatically. The purpose of the
> >> cache was to limit the number of file stats (QFile::exists()) calls.
> >> Items can go into the cache if:
> >> - findRealKey is called on them, and they are not yet in the cache
> >> - the cache is completely refreshed (this runs two entryLists() calls
> >> and puts all files from cur and new into the cache)
> >> - items are copied/moved inside the resource with the Maildir lib
> >> methods
> >> 
> >> There is no automatic comparision of the cache time with the directory
> >> time, as that would involve a stat call, defeating the purpose of the
> >> cache.
> > 
> > Then I had a very wrong understanding of the how the cache works. My
> > impression was that it only speeds up operations but does never report
> > invalid data.
> > 
> > I would prefer to have a mode of libmaildir that lets it work properly by
> > itself, e.g. as described above.
> > 
> > stat'ing just the directory for consistency check should still be way
> > faster than stat'ing every file but would keep the API work in the way it
> > was intended to.
> 
> Sorry, I don't understand when would you stat the directory. Stating when
> it changes? For that you need to watch it, but if you watch, why stat?
> Stating at every findRealKey()? Then we didn't won anything.

For the consistent cache option one would need to stat whenever the cache 
could no longer be coherent.
That might not always improve performance, hence the agressive cache option.

Alternatively there could be an additional option to limit the life time of 
cached data.

> It would probably be possible to move the directory watching into the
> maildir lib, if that is what you want. Not that straightforward though, the
> watching needs to be disabled before certain operations are performed, we
> would have one watcher object per maildir folder, we need to forward the
> "dirty" signal to the resource, as that is used not only for cache, but for
> other things in the resource.

I don't think that makes sense in libmaildir. The cache is already quite an 
extensive change (and the threading issue still remains IIRC).

> Patches are welcome, or you/we can work on it at the sprint, although I
> have some other plans for it. ;)

Right :)

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20120921/37c1e542/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list