[haiku-development] Re: [GSoC proposal] IMAP FS - A few queries
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 21 Apr 2011 09:34:44 +0200 (MEST)
Simon Taylor<simontaylor1@xxxxxxxxxxxx> wrote:
> I have no doubt that Donn has very good knowledge of the IMAP protocol
> and can provide useful hints and tips, but he will not be involved in
> the GSoC decision making process.
While it's true that Donn is not part of the decision making process, it's not
the person that carries weight, it's their arguments that may or may not carry
weight :-)
Unfortunately, Ingo usually has very good arguments, anyway ;-)
> For me the real problem with storing mails as separate files in BFS is
> the performance hit. For example my Inbox has 18658 mails in it and
> Tracker takes an absolute age to list them all. Thunderbird on the other
> hand can present me a list instantly. I'm not sure how much of the
> slowness is due to BFS and how much to Tracker, but IMHO that's they key
> problem that I'd hope an IMAP-FS would solve.
Just delete the index file Thunderbird creates, and the difference should not
be that huge anymore (the inbox mail format will still be faster, but much more
comparable). AFAIK Beam also creates a cache for the mails, and therefore
manage to show the folders full of mail much faster.
Something like this could be introduced in Tracker, directly, and enabled via a
folder attribute (the cache would be rebuilt asynchronously when opened, the
cached contents could be shown rather fast in comparison).
BFS could also be sped up considerably for a task like this if we introduce a
call that fetches all attributes at once - syscalls are slow compared to other
function calls, and minimizing them is usually worthwhile. Iterating over a
directory already needs to read in each inode anyway in order to get its stat
info sooner or later, and its attributes are usually stored there as well.
Bye,
Axel.
Other related posts:
