[haiku-development] Re: Tracker optimization [was: Re: [GSoC proposal] IMAP FS - A few queries]
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 24 Apr 2011 11:02:14 +0200
On 2011-04-23 at 18:49:16 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote:
> Ingo Weinhold<ingo_weinhold@xxxxxx> wrote:
> > On Thu, 21 Apr 2011 09:34:44 +0200 (MEST) "Axel Dörfler"
> > <axeld@xxxxxxxxxxxxxxxx> wrote:
> > [cache]
> > 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.
>
> Sure. However things like the localizing feature make this quite a bit
> harder, unless you're okay with entries that suddenly change their name.
I would just show a "loading" icon in all fields of attributes that haven't
been loaded yet (including the localized name). Since loading the visible
entries would be prioritized, the fields should be filled in rather quickly.
Showing the initial view of the folder could even be delayed until the
attributes of the visible entries have been loaded (maybe with a short
timeout).
> In any case, a cache wouldn't necessarily need a refresh button, as it
> could be used only to show a somewhat instant (potentially outdated) view
> that is updated on the fly.
That would work, though I'd consider adding a cache only, if really
necessary. It just adds a bunch of complexity and problems (where to store it
(a folder attribute doesn't generally work), keeping it up to date, etc.).
> > > 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);
>
> Or maybe a:
> status_t BDirectory::GetNextEntryAndMetaData(BMessage& data)
> or even a method to retrieve more than one entry at a time (could be done
> internally, though).
>
> In any case, getting all meta data might be expensive, if the data is
> outside of the inode; if that isn't even shown (attributes can have
> arbitrary size even), the effect could be counterproductive. So it might be
> nice to select only a certain number of attributes, or even only those of
> the small data region.
Then the interface should probably be tailored much more towards what is
actually needed:
status_t BDirectory::GetNextEntry(dirent* entry, struct stat* statData,
const BAttributeSelector* attributesToRead,
BAttributeSet* attributes);
With BAttributeSelector describing which attributes should be read (probably
just a list of names, maybe with size limits) and BAttributeSet containing
the retrieved attribute data. The more interesting parts are the userland <->
kernel and FS interfaces, though.
CU, Ingo
Other related posts:
