A File Benchmark Nautilus falls down, Konqueror stands up well, Explorer beats both

Note subject change.

In comp.os.linux.advocacy, Tim Smith wrote on Wed, 22 Jun 2005 15:23:30 GMT

An interesting notion for a benchmark, that. Granted, I don't collect music so I'll have to content myself with 90,000 text files containing maybe their own self-identifier:

$ cat 1234.txt 1234 $

These are easily generated by a small bash shell script:

done; date

I am using ext3, which is admittedly not the highest performance system. Nor are the two systems identical in configuration, and Cygwin hampers Windows performance; ideally I'd use native Windows stuff.

Linux: 1.7 GHz Xeon, Gentoo, 2.4.25, 256 MB Windows XP: 2.8 GHz Xeon, 1.0 GB

Grains of salt available on request.

On Linux creating the files took 15 minutes, 48 seconds. Making a minor change to the script (replacing $i.txt withdev-null) indicates that a fair amount of this time is actually script and-or process and-or kernel file open overhead; it took 3 minutes, 17 seconds doing essentially two nothings 90,000 times. However, that still leaves 12 minutes, 31 seconds.

As it is, it's faring better than my Windows machine, which so far has created about 33,000 files after about 22 minutes of hard work. After 24 minutes 52 seconds I put it out of its misery, and now have 36,168 files to play with on my XP local disk. ls wc on that system takes 259 milliseconds to count them. This despite the substantial head start Windows should have here because it's on the beefier machine, though it may be hamstrung by Cygwin hacks. I may have to redo this using JScript or something.

Windows: 0. Linux: 1.

Once created, the files on Linux take all of 1.383 seconds to count, realtime, using ls wc. Granted, that's probably because it's all in cache, and ls is probably one of the dumber listers -- but it's fast, as it doesn't have to open the files in order to ascertain what's in 'em.

Nautilus fared less well. Apparently it does have a threading problem or event handling problem; while listing this rather large (and pointless) directory, the background window refused to respond to mouseclicks. After about 6 minutes I force-end it using Metacity's "it's not responding, shall I kill it" requester; Nautilus reinvoked without too much fuss. However, clearly it can't handle the problem at all, at least in the version I have handy.

For its part 'explorer .' came up extremely quickly (less than a second), displaying the files in perfect order. (Part of this might simply because NTFS has them in order already, using an internal btree. I'll admit I'm tempted to create them in random order, if I can, and see if explorer does something stupid.)

Windows: 1. Linux: 1.

Konqueror fared extremely well here, compared to nautilus; the system comes up with an entry page displaying a number of icons and a status "stalled". A progress indicator did its thing. The system started paging at this point but the window still came up in less than a minute. Konqueror then spawned a subthread or something and the icons started changing to reflect the contents of each file; the effect was to give each file a unique number within the icon itself. For some reason, however, it skipped 1.txt.

The Konqueror icons are clickable, giving a text editor (kedit, probably). For some reason konqueror gave up on its icon update; some of the icons are a blue-breastled yellow pencil, some of them a smaller much less obvious pencil with the aforementioned number (which is what I put in the file).

It's unfortunate that I have to downcheck Konqueror since Windows is clearly faster and performs better, and it's even more unfortunate that Nautilus fell down out of the gate and couldn't get up. (This is after Konqueror has to deal with its startup issues on my system; a KDE-based system may have better luck there.)

Windows: 2 Linux: 1.

Clearly some improvement is possible here, although one also has to ask the obvious question as to how one would deal with 90,000 files on any system without at least trying to put them into some sort of hierarchy.

After all this,

$ find . -type f xargs rm

took all of 5 seconds. XP did about the same in its cmd shell.

Final score:

Windows: 2. Linux: 1.

but there's ample cause for a rematch. :-)

-- It's still legal to go .sigless.