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, 3 Apr 2004 12:47:17 +0100
On 3 Apr 2004, at 07:25, mathew wrote:
>
On Mar 24, 2004, at 16:38, Alastair Houghton wrote:
>
> Actually I think Uli should be using the Carbon routines
>
> (FSCatalogSearch() I think, although I'm sure Uli knows more about
>
> Carbon than I do as it happens ;->) to scan for all MacPAD.url files
>
> on
>
> the disk, because that should really fly on HFS+ disks due to the way
>
> HFS+ works. It's much faster than the "find" command will *ever* be,
>
> especially on disks with lots of directories.
>
>
Interesting... Apple's documentation says that for maximum speed, you
>
should use the BSD APIs for file access. Which makes sense, if you
>
think about it, because Carbon is layered on top of the underlying
>
Darwin system.
Generally that's true. However, HFS and HFS+ use a B*-tree based
volume format that makes searching for e.g. all files with the
specified name on the volume *really* fast, provided you do it in the
right way. Using standard BSD APIs to search, you have to separately
search each directory on the disk... however, if you're searching an
HFS/HFS+ disk, then the Carbon File Manager can search by directly
reading through the volume's catalog file, which is a *much* quicker
way of addressing the problem.
This is, of course, implemented in terms of APIs exposed at the BSD
layer, *however*, the APIs in question are proprietary Apple APIs and
are not documented with the base system. You can get the documentation
for them here:
http://developer.apple.com/qa/qa2001/qa1327.html
but if you read that Q&A, you'll also see that Apple recommend that
people use the Carbon File Manager routines instead, primarily because
File Manager includes emulation for the equivalent functionality on
non-HFS volumes.
>
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?
That's just the point. With Carbon (or the Apple APIs at the BSD
layer) and an HFS volume, it *doesn't* trawl every folder on a big hard
disk. Using standard BSD APIs, that's exactly what it has to do.
As for Cocoa, I haven't checked the performance of
NSDirectoryEnumerator, but I imagine it's probably still using the BSD
APIs, in which case it won't be as fast (on HFS/HFS+) as the Carbon
routines.
Kind regards,
Alastair.
p.s. for those interested in algorithms, HFS/HFS+'s B*-Tree has a
different node format at different levels of the tree, and also stores
data in the leaf nodes, so it is also a B+-tree.
--
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.