To summarise what was discussed,
- I think the folder hierarchy problem is easily solvable as I always
traverse from top of the tree. If an entry for one of the folders is found
in my set I stop the traversal to lower leaves of the tree.
- I would be using NSSet to store my “restrict list”. Howeve
On Apr 14, 2014, at 9:01 PM, Ken Thomases wrote:
> You should obtain the resource identifier object of each URL using
> -getResourceValue:forKey:error: with NSURLFileResourceIdentifierKey, then
> compare those two objects using -isEqual:.
One thing to watch out for, though: the object returned
Also, if your folder hierarchy, traversal code, and checks can deal well
with it, you¹ll get better performance by short-circuiting based on upper
directory checks.
For example, if you know you¹re in /Downloads, don¹t compare against
/Documents/AboutUs.pdf. Just use the /Documents set of file obje
On Apr 15, 2014, at 7:45 AM, Alex Zavatone wrote:
> A good approach here would be to make a test case for NSArray and NSSet, a
> known set of files and simply test now long each takes.
In general I agree that it’s a good idea to test before optimizing. It’s common
for people here to start obs
Another wild thought, how about drop one layer lower to POSIX and use a little
bit of OpenCL? For every directory with content paths C[0..i] and the list of
restricted paths R[0..j] construct a matrix (using OpenCL) M[0..i, 0..j] where
M[i, j]=strcmp(C[i], R[j]) (strcmp() itself can be OpenCL co
To keep your NSSet you can store it as an array. There are conversion methods
like -[NSSet array] and +[NSSet setWithContentsOfArray:].
Also, you can try to determine if your code is running on SSD. SSD can be
iterated in parallel and GCD will help a little when parallelizing the search.
Sent f
A good approach here would be to make a test case for NSArray and NSSet, a
known set of files and simply test now long each takes.
On Apr 14, 2014, at 8:59 PM, Graham Cox wrote:
>
> On 15 Apr 2014, at 10:02 am, Varun Chandramohan
> wrote:
>
>> Lets say I walkthrough 1000 files and folders,
On Tue Apr 15 2014 12:41:50 GMT+1000 (PGT) Graham Cox wrote:
On 15 Apr 2014, at 12:03 pm, John Brownie wrote:
think you're an order of magnitude out. Searching an array is linear with the
length of the array, O(n), whereas a set or hash should be close to constant,
O(1), if there's not a b
On Apr 14, 2014, at 21:10 , Varun Chandramohan
wrote:
> I was thinking what if I want to keep this persistent?
This doesn’t sound like such a good idea. There’s nothing to guarantee that
your saved data will actually match the state of the file system the next time
you read it back. In partic
Thanks Guys,
Yes I was not planning to use -[NSURL isEqual:]. Interestingly, Graham¹s
suggestion was to use NSSet, I was thinking what if I want to keep this
persistent? I would be writing this set to a file? I have used NSArray
writeToFile before but I don¹t see that method for NSSet. Do I have t
On 15 Apr 2014, at 12:03 pm, John Brownie wrote:
> think you're an order of magnitude out. Searching an array is linear with
> the length of the array, O(n), whereas a set or hash should be close to
> constant, O(1), if there's not a big collision in the hashes. But the
> principle is correc
Graham Cox wrote:
As a general principle, if you have to check whether one of a list of things is
part of another list of things, an array is the wrong container for the job,
because it amounts to a worst-case O(n^2) search. Instead, use a set or hash
table for the set of things that must be d
On Apr 14, 2014, at 7:02 PM, Varun Chandramohan wrote:
> I have a question about efficiency when trying to compare NSURL. The
> requirement is quite simple. I try and iterate through a directory to all
> subdirectories and files. While doing this walk-through, I need to check
> against an array
On 15 Apr 2014, at 10:02 am, Varun Chandramohan
wrote:
> Lets say I walkthrough 1000 files and folders, for each file/folder I need to
> compare against this array list. This might be slow or inefficient. Is there
> a faster way to do something like this?
As a general principle, if you have
14 matches
Mail list logo
