Writing a file manager is definitely a quite special kind of fun. Despite a seeming simplicity there’s a lot of details that should be considered when implementing it. Using efficient structures, algorithms and architecture can mean much, regardless that all remains under the hood and is not visible to user. Since the main purpose of a file management app is navigation between folders and showing their’s content, I’ve managed to perform some tests to show how different implementations can handle this (quite simple?) task. At the moment my collection of Mac OS X file managers was 11 different ones (all this software can be easily found in Google, also I don’t claim I’ve tested all file managers for Mac OS X – there’re others).
OK, to be precise – this is a stress test. By stress I mean not a usual stress, but STRESS.
The job is very simple: reading and showing a content of a directory with 1,000,000 files. Nothing more, just it. I’ve taken my old 8Gb USB stick, plugged it into my Macbook Pro running OS X Mavericks and formatted it into HFS+ journaled, also turned off Spotlight on this volume. Then run a tiny app, which I called fs_killer 🙂
int main(int argc, const char * argv[]) {
  char tmp[MAXPATHLEN];
  for(int i = 0; i < 1000000; ++i) {
    sprintf(tmp, “/Volumes/test/%6.6d.txt”, i);
    close(open(tmp, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR|S_IRGRP));
  }
  return 0;
}
Here’s the test itself: run an app, check if it will be able to open this folder, record how much memory it has consumed and check if app is still usable (cursor movements and scrolling ability). Every app was given a plenty of time to load the directory listing, and this parameter wasn’t counted. The comparison table in alphabetical order is below:
| Application name | Opened | Memory | Usable |
|---|---|---|---|
| DCommander | yes | ~1.7Gb | yes |
| FastCommander | yes | ~1.1Gb | yes |
| Nimble Commander | yes | 150Mb | yes |
| Finder |
yes
|
~2Gb | yes |
| ForkLift | yes | ~1.7Gb | yes |
| Macintosh Explorer | yes | ~1Gb | yes |
| Midnight Commander | yes | 133Mb | yes |
| Moroshka File Manager | yes | 160Mb | no |
| Mover | yes | ~2Gb | no |
| muCommander | no | n/a | n/a |
| ZCommander | yes | 850Mb | yes |
A few words for conclusion. Two things can be clearly seen:
1) Midnight Commander (mc) is the winner (and the only to run in console) and muCommander is very bad – it was the only one to fail the opening test.
2) These file managers can be divided into 2 groups by memory consumption: less than roughly 200Mb and above it. I suppose this difference to be consequence of an internal data storage structure – while the first group relies on plain C / C++ memory management, the others use Objective C / Cocoa infrastructure to handle directory listing data, which is considerable less efficient in this aspect.
As the bottom line I can only give a link to Nimble Commander, it’s free now: http://magnumbytes.com/
One Reply to “A “million files” test”