How Background Indexing Affected Mac OS 9 Performance

During heavy workloads, the background indexing feature in Mac OS 9 significantly degraded system responsiveness, often leading to severe input lag, disk thrashing, and system freezes. Because Mac OS 9 relied on a legacy architecture lacking preemptive multitasking and memory protection, background tasks like Sherlock’s "Find by Content" indexing actively competed with foreground applications for critical hardware resources, routinely bringing high-demand workflows to a crawl.

The Constraint of Cooperative Multitasking

Mac OS 9 utilized cooperative multitasking, an architecture where running applications had to voluntarily yield processor time back to the operating system. When Sherlock initiated background indexing, it ran as a background process designed to parse the text contents of every file on the hard drive. Under heavy usage—such as video rendering, audio production, or compiling software—this cooperative model broke down. The background indexer frequently failed to yield CPU cycles quickly enough, resulting in dropped frames, stuttering mouse cursors, and the infamous spinning watch cursor appearing over foreground applications.

Severe Disk I/O Bottlenecks

In the late 1990s and early 2000s, consumer storage relied on mechanical hard drives with limited read and write speeds. Background indexing required continuous, sequential reads of thousands of files across the file system. When an active application simultaneously attempted to read or write project files, the hard drive’s read/write heads were forced to seek rapidly between the target files and the indexer’s tasks. This disk thrashing saturated the system's I/O bandwidth, causing foreground programs to hang while waiting for simple disk access requests to clear.

Memory Exhaustion and System Instability

Mac OS 9 lacked modern protected memory. Every application and system extension operated in a shared memory space with statically allocated RAM partitions. As Sherlock processed large directories, archives, or complex document formats, its memory footprint expanded. If it encountered deeply nested directories or corrupted files, the indexer could run out of its allocated memory buffer. Because memory was not protected, an indexing error could crash the Finder, cause system-wide "Type 1" or "Type 10" errors, and force a complete hardware reboot, resulting in lost work for users running heavy tasks concurrently.

User Mitigation and Disabling the Feature

Because the performance penalty was so steep during intensive tasks, automatic background indexing became widely regarded as a liability for professionals. The standard troubleshooting advice and setup practice for power users was to open Sherlock’s preferences, disable scheduled indexing across all mounted volumes, and in many cases, disable or remove the indexing system extensions entirely to preserve maximum system stability and speed.