> The volume ID is at a higher layer, but the enumeration code attempts to
> retrieve the value less than once per URL returned. That said, if the
> directory hierarchy has few items per directory, the number of times it is
> retrieved will be higher. You can write a bug report and I'll look to
Quick update:
> -[enumeratorAtURL:includingPropertiesForKeys:options:errorHandler:] also
>> supports recursive enumeration (which stops at device boundaries -- you'll
>> see mount points but not their contents) so you don't have to do that
>> yourself.
>>
>
This is indeed faster than most of the
> On Apr 29, 2019, at 1:19 PM, Thomas Tempelmann wrote:
>
> Jim,
>
> In contentsOfDirectoryAtURL, instead of "includingPropertiesForKeys:nil", use
> "includingPropertiesForKeys:@[NSURLVolumeIdentifierKey]" (and add whatever
> other property keys you know you'll need). The whole purpose of
Jim,
In contentsOfDirectoryAtURL, instead of "includingPropertiesForKeys:nil",
> use "includingPropertiesForKeys:@[NSURLVolumeIdentifierKey]" (and add
> whatever other property keys you know you'll need). The whole purpose of
> the includingPropertiesForKeys argument is so the enumerator code can
In contentsOfDirectoryAtURL, instead of "includingPropertiesForKeys:nil", use
"includingPropertiesForKeys:@[NSURLVolumeIdentifierKey]" (and add whatever
other property keys you know you'll need). The whole purpose of the
includingPropertiesForKeys argument is so the enumerator code can
Doing more performance tests for directory traversal I ran into a
performance issue with [NSURL contentsOfDirectoryAtURL:]:
See this typical code for scanning a directory:
NSArray *contentURLs = [fileMgr contentsOfDirectoryAtURL:parentURL
includingPropertiesForKeys:nil options:0 error:nil];
I don’t really have time to look at the current fts implementation, but… it has
several options that effect performance (in particular, the FTS_NOCHDIR,
FTS_NOSTAT, FTS_NOSTAT_TYPE, and FTS_XDEV options). If you are trying to
compare fts to CFURLEnumerator (for example), use FTS_NOCHDIR and
On Apr 22, 2019, at 9:59 AM, Thomas Tempelmann wrote:
> Can you give some more information about the fts implementation? Is this
> user-library-level oder kernel code that's doing this? I had expected that
> this would only be a convenience userland function that uses readdir or
> similar BSD
Jim,
thanks for your comments.
If all you need is filenames and no other attributes, readdir is usually
> faster than getattrlistbulk because it doesn't have to do as much
> work. However, if you need additional attributes, getattrlistbulk is
> usually much faster. Some of that extra work done
>
If all you need is filenames and no other attributes, readdir is usually faster
than getattrlistbulk because it doesn't have to do as much work. However, if
you need additional attributes, getattrlistbulk is usually much faster. Some of
that extra work done by getattrlistbulk involves checking
I like to add some info on a thread from 2015:
I recently worked on my file search tool (FAF) and wanted to make sure that I
use the best method to deep-scan directory contents.
I had expected that getattrlistbulk() would always be the best choice, but it
turns out that opendir/readdir perform
11 matches
Mail list logo
