[haiku-development] Re: [GSoC proposal] IMAP FS - A few queries
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 22 Apr 2011 04:22:30 +0200
On Thu, 21 Apr 2011 09:34:44 +0200 (MEST) "Axel Dörfler"
<axeld@xxxxxxxxxxxxxxxx> wrote:
> Simon Taylor<simontaylor1@xxxxxxxxxxxx> wrote:
> > 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).
Unless you're OK with a "Rebuild Cache"/"Refresh" button/menu item (which Beam
has BTW), a cache isn't such a help, since you'd have to stat() all files
anyway. I think a lot can be done by loading a folder more intelligently. In
list mode one basically only needs a complete directory listing to already show
the list. The details can be loaded in the background, with the currently
visible items being prioritized.
> 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.
Syscall performance certainly contributes to the slowness, but considering that
"ls -l" is an order of magnitude faster showing an already cached directory of
attributeless files, there're obviously other issues as well.
> 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.
I'm seeing a
status_t BEntry::GetAllMetaData(BMessage& data);
:-)
CU, Ingo
Other related posts:
