Phil Dietz, the author of NewList, claims that NewList version 6.0 is faster than Dr 1.3, and produces some benchmark timings to back up this claim. What he does not say, though he knows it perfectly well, is that his timings were better ONLY in the case of a non-recursive scan of a Fast File System directory; he gives no timings for either recursive descents into subdirectories, or for scans of floppy disks or other SFS disks, knowing that Dr has always been faster in those cases. Furthermore he does not mention that the main reason NewList was faster in those cases was simply because he wrote less whitespace in the output than Dr did, and turned off the text cursor to make the console write a bit faster. In one earlier version of his timing comparisons, he chose filenames of a length such that Dr output one fewer columns than NewList did. And frankly, my test results are a lot less flattering to NewList relative to Dr than his are, even under conditions as similar as possible. I just don't know how trustworthy his numbers actually are. (Maybe we've each optimized for our own particular hardware configurations?) Well, he did at one time have a SLIGHT legitimate speed advantage in those limited conditions, BUT NOT ANY MORE. He picked the wrong hacker to provoke ... Dr 1.5 is now faster than NewList will EVER be (unless he starts using my fastscan.library, in which case he'll have to give me the credit for the speed he brags about), in all cases. Here are some timings ... each comparison was done under four sets of conditions, labeled as follows: con-7: Done on a 7.14 MHz Amiga 1000 with slow-fast ($C00000) ram under AmigaDOS 1.3.2, with output written in Topaz 8 font to a 640 x 101 console window on a four color non-interlaced screen, with text writing sped up by FF. Unless otherwise stated, the disk being scanned was a 65 meg (28 ms seek time) FFS hard drive, about half full and recently optimized (I would have liked to test on a fragmented disk but I wasn't about to go fragmenting it on purpose), with a slow RLL controller. nil-7: Just like con-7 except that output was redirected to NIL:. con-25: Done on a 25 MHz Amiga 3000 with SCRAM under AmigaDOS 2.04, with output written in Topaz 11 font to a 640 x 150 simple-refresh console window on a four color interlaced screen, with scrolling sped up by CPUblit. Unless otherwise stated, the disk being scanned was a 75 meg FFS partition of a stock internal 100 meg Quantum SCSI hard drive, about two thirds full without very much fragmentation. nil-25: Like con-25 except that output was redirected to NIL:. Three trials were averaged in all cases. Times are in seconds, measured with the program "Time", included -- this method is more accurate than any manual stopwatch. All tested programs were made resident. Three versions of Dr were tested, referred to here as Dr3, Dr5bare, and Dr5lib. The first is the release 1.3 version of Dr, the others are a beta version of release 1.5 -- "bare" means fastscan.library was not installed, "lib" means the library was in use. The version of NewList tested was release 6.0, using the dos 1.3 version for the A1000 tests and the dos 2.0 / 68020 version for the A3000 tests. I compared these with Commodore's Dir and List programs, and with ls version 4.1ljr (which Phil Dietz likes to call "LS 4.11 jr", since he is apparently unable to distinguish a lowercase L from a numeral one). Alphabetized multi-column listing of 600 empty files with longish names: con-7 nil-7 con-25 nil-25 Dir ** Failed! ** 9.27 4.16 ls4.1ljr -a 30.0 20.4 8.89 4.72 NewList6 -qv 21.1 19.3 7.64 4.47 Dr3 -i 17.3 11.4 7.12 3.51 Dr5bare -!i 15.7 11.5 6.94 3.79 Dr5lib -!i 15.6 11.5 6.64 3.50 NewList6 -qvR 21.2 19.3 7.64 4.46 Dr5lib -!ir 14.0 9.77 4.67 1.49 <- dig that number! Notes: all programs wrote three columns of names except for Dir which wrote two. Given a narrower window, all wrote two columns except for ls 4.1ljr which still wrote three -- this error gave it much slower times in that case. Under those conditions the con-25 time for NewList6 was almost exactly the same as that of Dir (note Dir's better nil-25 time). The last two times compare NewList to Dr when using the recursive-subdirectory-listing options when no subdirectories are present. This doesn't change NewList's times... but Dr actually speeds up. I did not make it use this optimization in all cases, though, because sometimes in small dirs it can slow it down. Unsorted listing with size, date, and protection of 600 empty files: con-7 nil-7 con-25 nil-25 List 35.3 22.6 14.2 4.11 ls4.1ljr -al 39.6 22.2 15.4 4.76 <- sorted NewList6 26.1 13.0 13.2 3.46 Dr3 -il 30.8 13.3 14.2 3.87 <- sorted Dr5bare -!ol 27.8 14.1 13.3 4.18 Dr5lib -!ol 25.4 13.4 12.3 3.19 Dr5lib -!olr 24.1 12.0 10.9 1.73 Notes: Dr 1.3 was not able to include size, date, and protection in an unsorted listing, so the times are for an alphabetically sorted listing. It turns out that ls 4.1ljr is actually SLOWER when you don't sort ... why this could be I have no idea ... anyway I showed the better sorted times above. NewList is at its best in this comparison. Again, the last number is with the recursive-descent option when no subdirectories are present. Columnated recursive listing of entire hard drive, each directory alphabetized: con-7 nil-7 con-25 nil-25 Dir opt a 142.1 95.3 71.5 34.4 ls4.1ljr -aR 132.2 74.0 62.6 35.4 NewList6 -qvR 108.0 73.7 64.3 36.9 Dr3 -ri 94.5 52.7 60.9 32.5 <- bug Dr5bare -!ri 105.4 65.9 55.9 32.1 Dr5lib -!ri 91.1 51.6 43.4 19.2 Notes: Dr 1.3 has a bug which makes it incorrectly put up a frightening requester saying "Volume foo has a read/write error" when the -r option is used on an A3000 hard drive. Once this requester is canceled, it produces correct output. The con-25 and nil-25 times for Dr 1.3 include the time taken to cancel the requester. This same bug also makes the times comparable to Dr 1.5 without fastscan.library rather than with. After using a disk optimizer, the nil-25 time for Dir improved to 29.2 seconds, NewList improved to 31.4 seconds, and that for Dr with fastscan.library improved to 11.7 seconds, a seriously amazing number. Sending Dr's output to ram: instead of nil: so that the output was usable took 0.6 seconds longer -- in this case it was listing files and directories at a rate of 329 per second. Columnated listing of directory on floppy with 300 empty files: con-7 nil-7 con-25 nil-25 Dir 129.4 125.7 11.7 9.88 ls4.1ljr -a 125.7 120.8 11.3 9.68 NewList6 -qv 122.2 120.5 11.2 9.32 Dr3 -i 15.9 12.5 10.6 8.47 Dr5bare -!i 122.2 119.2 10.4 9.08 Dr5lib -!i 15.0 12.0 10.0 8.38 Notes: on disks that do not use the Fast File System, the advantage of using Dr under dos 1.3 and older becomes quite extreme. Some of those numbers look like I slipped a decimal place or something, but they are correct. Columnated recursive listing of a very full and fragmented floppy: con-7 nil-7 con-25 nil-25 Dir opt a 80.5 77.7 44.3 41.7 ls4.1ljr -aR 83.8 79.3 48.0 45.9 NewList6 -qvR 82.6 80.1 48.2 45.8 Dr3 -ri 42.9 39.8 35.3 33.9 Dr5bare -!ri 78.9 76.1 44.1 41.3 Dr5lib -!ri 42.0 39.4 35.2 33.9 Notes: NewList in this case is slower than Dir, but not as slow as ls 4.1ljr. But it's much improved over NewList 5.0, which was not only slower but ate HUGE amounts of ram when -R was used. Conclusion: Dr 1.5 with fastscan.library is fastest. Always. Fastscan.library is a moderate advantage on FFS disks, or under 2.0 ... but on floppy disks under 1.3 it is a NECESSITY. Dr's advantage seems to be least on disks that are moderately fragmented. On severely fragmented disks it can have a strong advantage under 1.3, and on completely defragmented disks it has the biggest advantage of all. I noticed one potential problem with NewList while doing this: it does not clear the dos error code (IoErr) when it finishes successfully. If it is executed from inside another program, that other program (which, if it uses the Execute function, cannot know what its return code was) can only assume that if IoErr is nonzero, the program being run has failed. There are programs which do make such assumptions when using Execute... Options... If you want to compare QUANTITY of options, NewList is way ahead, but all those options add up to almost nothing that Dr can't do more easily ... compare his DPat script with mine -- mine uses only one Dr command, his still needs a bunch of IFs. But on the other hand ... NewList can sort by filenote! Wow!