I would suggest to count the number of files asynchronously if possible, so the user doesn’t have to wait for this information in order to begin working with the panel.
A couple of years ago I had to split by file type an enormous amount of restored files from a corrupt hard disk that were inside a few folders, because we couldn’t even browse them. The Python script that did the job of moving the files around, initially used Python functions and later “ls” to get the list of files, but it would get unresponsive for a long time before it started working and used tons of memory. I later wrote a simple command line utility that would traverse a given directory and print the filenames to stdout in small batches, using “getdirentries()” — try “man getdirentries” and “man dirent” for a manual — which, combined with Python’s generators, worked beautifully. Anyway, essentially the problem is that “ls” and several system/framework functions call down to system routines and wait until all files have been read or large buffers are filled before they begin work. Whatever you do, the total time it takes to read the contents of a huge directory via lower-level calls (i.e. lower-level than Cocoa), will most likely be more or less the same. But you can instead do work and update the UI in batches, instead of once in the end when you have the total count. You may find the command line program here [1]. Use it however you like, usual disclaimers apply :) Best, Akis [1] https://gist.github.com/dfunckt/055d9a275039d4134558 > On Nov 13, 2015, at 8:28 AM, Jonathan Taylor <jonathan.tay...@glasgow.ac.uk> > wrote: > > Hi all, > > I want to be able to identify quickly (programatically) how many image files > reside in a particular directory. At present I call: > [NSFileManager defaultManager] contentsOfDirectoryAtPath:dir error:nil]; > and then examine the type suffixes (which in comparison is very quick). When > looking at a directory over a network or on an external drive, the > NSFileManager call can take several seconds for a directory containing 18k > files of which half are images. > > These sorts of numbers are in fact a common use case for me, and I would like > to avoid this delay. This is for preview information in an NSOpenPanel, so I > don't want to make things this unresponsive - but at the same time it is very > useful to have access to this information for the preview. > > Can anybody advise on a quicker way of achieving what I want to achieve? The > fact that 'ls' takes almost as long makes me think this is probably a fairly > insurmountable problem, but at the same time the quantity of information > transferred (of the order of 200k of data) should not take 2 seconds to > transfer, so in that sense it doesn't seem unreasonable to try and see if > there is a faster way. > > I would prefer to get the filenames themselves, but I could settle for just a > count of the total number of files (of any kind) in the directory *and* the > ability to get the paths of just the first few files in the directory, if > there might be a faster way of doing that. > > Thanks for any suggestions > Jonny _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
