On 19 Aug 2009, at 10:47, Charles Srstka wrote:
On Aug 19, 2009, at 4:24 AM, Alastair Houghton wrote:
As I think I may have mentioned before, contrary to apparently
widespread opinion, Carbon isn't magic. The Carbon file manager
APIs are based on BSD APIs, and calling the BSD APIs in question is
going to be faster if you really need high performance because they
don't have to map things to the Carbon API's data structures and
back again.
I *knew* I'd read somewhere that this wasn't true - that the Carbon
file manager doesn't use the same opendir() / readdir() APIs that
you'd use if you were doing this the BSD way,
Yep.
and that someone had benchmarked Cocoa vs. Carbon vs. BSD, and
Carbon came out on top. What I didn't remember was that it was you
who did it:
http://www.cocoabuilder.com/archive/message/cocoa/2004/4/3/103325
http://www.cocoabuilder.com/archive/message/cocoa/2004/4/3/103327
Yep.
Carbon *does* use BSD-level APIs to do what it does (there are only a
couple of cases I'm aware of where Carbon is using SPI for filesystem
operations instead, and IIRC the SPI in question is mainly useful for
implementing Carbon, rather than for any other purpose).
The issue is mainly that the APIs in question (things like searchfs(),
get/setattrlist() et al) are not guaranteed to be supported on any
given volume format and you need to use getattrlist() with
ATTR_VOL_CAPABILITIES. Carbon's equivalent APIs work whether or not
the equivalent BSD API is supported on the volume you're working with.
Have things changed in this regard in the intervening years since
2004?
Well if you look at the end of the first post, you'll see that I
mention the BSD layer searchfs() API there...
Carbon is usually a good way to go, because you don't need to check
the volume caps first---Carbon just uses a different method of
achieving the same goal if it can't use the APIs it ideally wants to.
If you use the BSD layer yourself, you have to implement the same kind
of thing yourself, and usually there's no point.
I'll also note that my post from 2004 was about scanning the *entire*
disk (which is the absolute best case for FSCatalogSearch() or searchfs
() compared to opendir()/readdir()); you won't see such a huge
advantage for recursively scanning sub-trees.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
