Re: SLOW -[NSFileManager directoryContentsAtPath:matchingExtension:options:keepExtension:]
Re: SLOW -[NSFileManager directoryContentsAtPath:matchingExtension:options:keepExtension:]
- Subject: Re: SLOW -[NSFileManager directoryContentsAtPath:matchingExtension:options:keepExtension:]
- From: Paul Forgey <email@hidden>
- Date: Tue, 11 Apr 2006 13:29:21 -0700
Anything in user mode goes through the system calls, which in theory is
spelled out in /usr/include/unistd.h. This is how unixes work. Carbon,
Cocoa, the Java JM, everything funnels down to this point to make calls
to the kernel, which is needed to do anything with I/O, like reading
files or directories.
Directories are just files when you read them. opendir/readir/closedir
are actually implemented in user mode in libc by parsing the data from
reading the directory with open/read/close (those are the system calls)
since the exact format is operating system dependent, although not
filesystem dependent since the kernel takes care of that for us when
giving us the contents of the directory.
Maybe you could argue which way is faster under which circumstance, but
short of parsing the directory content yourself, the libc functions
opendir and friends are going to be the most _direct_ way there.
How you handle the results can impact performance a lot, like if you
need the mtimes, permissions, attributes, etc. All you get from the
directory contents is the name. Given the name, you then dig out the
further things you need with stat (), get*() and stuff.
Will Mason wrote:
Hi, Ondra,
Yes, I see your point. However, everyone is going to be at least one layer removed from HFS+ calls, because there's no way to know in advance the type of file system in use. What if the directory is mounted over NFS? Then, if Carbon weren't abstracted off of that, it would fail to work at all. My guess is that the BSD calls are using kernel calls directly. It's just a guess, though; I'd be the first start eating my hat if I were wrong.
I'll stop talking because I don't have time to test all the options and compare them.
Cheers,
Will
----- Original Message ----
From: Ondra Cada <email@hidden>
To: Will Mason <email@hidden>
Cc: email@hidden
Sent: Tuesday, April 11, 2006 11:22:56 AM
Subject: Re: SLOW -[NSFileManager directoryContentsAtPath:matchingExtension:options:keepExtension:]
Will,
On 11.4.2006, at 18:14, Will Mason wrote:
There's also nothing wrong with using BSD calls: opendir(3), readdir
(3), closedir(3). I'd be willing to bet (without empirical data)
that those are actually the fastest of any of the proposed options.
In pure theory, Carbon should be faster (for it can exploit the fact
its calls are HFS-native, whilst posix has to be at least one level
higher).
In practice it might not be so--I haven't profiled them.
Anyway, myself, I would use the posix level only if truly needed for
portability, but YMMV.
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden