Re: Fast file access (was Re: [ANN] Shovel - Third-Party "Software Update")
Re: Fast file access (was Re: [ANN] Shovel - Third-Party "Software Update")
- Subject: Re: Fast file access (was Re: [ANN] Shovel - Third-Party "Software Update")
- From: Alastair Houghton <email@hidden>
- Date: Sat, 10 Apr 2004 10:10:16 +0100
On 10 Apr 2004, at 00:32, Daniel Waylonis wrote:
>
On Apr 3, 2004, at 4:57 AM, Alastair Houghton wrote:
>
>
> On 3 Apr 2004, at 07:25, mathew wrote:
>
>
>
>> Anyone feel like doing some speed comparisons between Cocoa, Carbon
>
>> and BSD for trawling every folder on a big hard disk, to put this
>
>> one to rest?
>
>
>
> Some figures I just obtained for a search of every file and directory
>
> on my hard disk:
>
>
>
> Carbon (using FSCatalogSearch) 54.9 seconds
>
> Cocoa (using NSDirectoryEnumerator) 148.1 seconds
>
> BSD (using opendir(), readdir() et al.) 129.1 seconds [...]
>
>
Hi Alastair,
>
>
You might have better luck with fts() (man fts) on the Posix side.
fts is implemented in terms of opendir(), readdir(), stat() et al., so
whilst it's true that it's a better API for many applications, it's
unlikely to be faster. One of the main reasons to prefer fts() is that
it won't break if the directory hierarchy changes, whereas if you scan
using opendir() and readdir(), you have to be careful (or you have to
know that the disk structure isn't going to change). However, for my
test, I just wanted to demonstrate the the Carbon APIs were
substantially quicker than the BSD ones.
>
I did some testing against FSGetCatalogInfoBulk() (the fastest) and
>
found that it was pretty close in performance.
>
>
Scanning "/Library/Developer":
>
>
fts 8675 Directories, 51908 files (7.8 sec - 13.9 sec)
>
FSGetCatalogInfoBulk 8674 Directories, 55678 files (2.9 sec - 3.3 sec)
>
(128 directory entries at a time)
>
>
I'm not sure why there's a discrepancy between the # of directories &
>
files, but it the fts is probably skipping invisible files.
That doesn't look "pretty close". According to your figures,
FSGetCatalogInfoBulk() is between 3 and 4 times as fast as fts.
As far as the Carbon APIs go, FSCatalogSearch() is almost certainly
quicker for recursive searches of the entire disk, because that's what
it's intended for. It also only uses a single iterator, and you can
specify match criteria.
Obviously if you want to search a particular subtree, you can't use
FSCatalogSearch() because it only supports iterating recursively from
the root directory; in that case I agree, you'd use
FSGetCatalogInfoBulk() and program-in a recursive-descent search of
some description.
It'd also be worthwhile investigating whether you can use SearchKit; I
believe the Finder uses it to create an index of the disk contents that
should be even faster to scan than the File Manager APIs. Nevertheless,
I think we're all agreed that the BSD APIs are slow compared to some of
the alternatives.
Kind regards,
Alastair.
--
http://www.alastairs-place.net
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.