Uli's Web Site
[ Zathras.de - Uli's Web Site ]
Other Sites: Stories
Pix
Abi 2000
Stargate: Resurgence
Lost? Site Map!
 
 
     home | blog | moose | programming | articles >> blog

 Blog
 
 Archive
 
 Blog Topics
 

15 Most Recent [RSS]

 Less work through Xcode and shell scripts
2011-12-16 @600
 
 iTunesCantComplain released
2011-10-28 @954
 
 Dennis Ritchie deceased
2011-10-13 @359
 
 Thank you, Steve.
2011-10-06 @374
 
 Cocoa Text System everywhere...
2011-03-27 @788
 
 Blog migration
2011-01-29 @520
 
 All you need to know about the Mac keyboard
2010-08-09 @488
 
 Review: Sherlock
2010-07-31 @978
 
 Playing with Objective C on Debian
2010-05-08 @456
 
 Fruit vs. Obst
2010-05-08 @439
 
 Mixed-language ambiguity
2010-04-15 @994
 
 Uli's 12:07 AM Law
2010-04-12 @881
 
 Uli's 1:24 AM Law
2010-04-12 @874
 
 Uli's 6:28 AM Law
2010-04-12 @869
 
 Uli's 3:57 PM Law
2010-04-12 @867
 

More...

Thomas Tempelmann on file system speed on OS X

Thomas Tempelmann posted a neat little piece on the features and abilities of CoreFoundation's File Manager (formerly known as the Carbon File Manager). Particularly he mentions how its FSRef architecture gives you much better performance for file listing than the path-based POSIX APIs. A short but informative read for anyone who has to do a lot with files.

Reader Comments: (RSS Feed)
Aaron Ballman writes:
So that makes me curious: does Apache on the Mac use POSIX paths, or FSRefs? What about other file-system intensive applications? Surely the path/inode-based APIs aren't going to be exponentially slower than FSRef APIs. I doubt Apple re-wrote all of the core utilities (ls, find, etc) that make up the OS to use File Manager calls instead, and the system is certainly responsive enough.
Ahruman writes:
Aaron the point is not that paths are slower on OS X than on other systems, but that FSRefs are inherently faster than paths. (In potentia, anyway; obviously they could be implemented badly.)
Jean-Daniel Dupas writes:
If you want to be exact, it the Core Services's File Manager, not the CoreFoundation's one. I really like the FSRef concept and miss it when I have to work on other system. I hope futur OS X file systems will keep this concept.
Uli Kusterer replies:
@jean-daniel Thanks for the correction. Peter Hosey also mentioned that it's actually in CoreServices, and of course you're both right.
Thomas Tempelmann writes:
I just found this page after asking ask.com "who is" me. Everyone does that sometimes, don't you? Anyways. Snow Leopard (10.6) will introduce a new API that replaces FSRefs with CFURLs - those are, other than FSRefs, reference counted, which allows the OS to manage the needed refs and discard of the obsolete ones. Which is important on Macs that access a lot of remote volumes, where the ref information wouldn't fit into a FSRef (which is a container of a fixed size, i.e. 80 bytes). CFURLs get dynamically alloc'd and the user only holds a ref to it. That way, the lower FS levels are able to define the amount of storage the need for a ref to an object of their domain. So, from 10.6 on, forget paths, forget FSRefs, be merry with CFURLs!
Comment on this article:
Name:
E-Mail: (not shown, hashed for Gravatar)
Web Site URL: (optional)
Comment: (plain text only)
Please Enter the following word:
Or E-Mail Uli privately.

 
Created: 2008-06-05 @068 Last change: 2014-08-01 @449 | Home | Admin | Edit
© Copyright 2003-2014 by M. Uli Kusterer, all rights reserved.