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. 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. > 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. Sure, it just all adds up :-) > > 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. Bye, Axel.