|
File Copying Performance under Classic MacOS, MacOS X and Linux Objective: Test file copying performance (large directory/small files, large directory/large files) under Classic MacOS (v 9.1), Classic MacOS running under MOL (Mac On Linux emulator), MacOS X and Linux on the same hardware. Hardware: Apple iBook FireWire (Summer 2000) model, 366 MHz PowerPC G3 CPU, 256 K L2 Cache, 320 MB RAM, 10 GB HD internal IBM 4200 rpm HD, partitioned - 6 GB for HFS+ MacOS and the rest for Linux. MacOS Classic Software: real-world MacOS 9.1 (e.g. with all my extensions, including ATM), extensions on, virtual memory on (RAM size + 1 MB), 1500 KB disk cache, AppleTalk on, file sharing off. MacOS X Software: MacOS X v10.0.3, installed on the same HFS+ formatted partition as MacOS 9.1, AppleTalk on, File Sharing off. Linux Software: SuSE Linux 7.1, kernel 2.4.2, GLIBC 2.2, single ReiserFS partition, 96 MB swap partition, MOL (Mac on Linux) emulator 0.95.8-1 running in X (slow video) mode, 160 MB of RAM allocated for MacOS 9.1 running under MOL, KDE 2.1.2, GNOME 1.2, running services - Apache, Postfix, CUPS, NFS, Netatalk, XFree86. Test Folders: directory of 5200 Mac files and folders (170 MB total); directory of 31 large graphic files (341 MB total). Test Conditions: Two test folders have been duplicated on Mac HFS+ and Linux ReiserFS partition accordingly; using Finder on MacOS, and under Linux with UNIX cp command, Midnight Commander 4.5.51 (often referred as MC), Konqueror (KDE 2.1.2 Desktop), GMC (GNOME 1.2 Desktop). There are no standard method of copying files under Linux, as well there are no default desktop environment (you can use either KDE or GNOME under X either Midnight Commander in console mode). Notes: These tests are somewhat unfair to Linux. First of all, Linux was installed on ReiserFS partition. ReiserFS is a crash-proof journaling file system which maintains log of all transactions and replays log in case of system crash or power failure, thus keeping file system consistent. ReiserFS compromises performance for extra reliability. Second, 5200 Mac files and folders turned into 9906 Linux items. For each Mac file Linux creates additional item stored inside invisible AppleDouble directory (located at the same level as original file), which contains Mac-specific information (e.g. resource fork). Copying almost doubled number of items will certainly need more time. Special Notes: For second test I have deleted Linux AppleDouble directory to exactly match number of items. These files do not have resource fork anyway, so loss of extra Finder info is not significant.
The results above should not be misinterpreted. Apple iBook is equipped with UltraATA interface which characterized by high CPU load - it was around 40 - 60%, sometimes even 80% while MacOS X Finder did the copy tests (do not forget, iBook is an entry level and cheap portable). MacOS 9.1 was the fastest because nothing else have been running. MacOS 9.1 uses cooperative multitasking (each task consumes as much CPU resources as he wants), while MacOS X and Linux use preemptive multitasking (special piece of system software called scheduler divides CPU resources between different tasks). So, MacOS X was the best performer with Linux trailing little behind (again, Linux was installed on crash-proof journaling file system). However, Linux file managers like GMC and Konqueror clearly cry for file copying routine optimization (Linux users will probably argue that none of them used anyway when Linux runs as server ). The question remains why MacOS 9.1 running under Mac On Linux emulator have lower scores than MacOS 9.1 in native mode, despite other tests showed opposite? This is the side effect of cooperative multitasking: MacBench takes the whole control over the system, while Finder allows other tasks to run. |
