Leopard Review Notes
Apple's focus is on system-level performance, not micro-benchmarks. The kernel team's job is to make the software at the higher levels look good. If improving the performance of some tiny aspect of the kernel tenfold does not provide a measurable performance increase for some user-visible feature or task, it's not an effective use of development time, benchmark bragging rights be damned.
I do not believe that this explains OS X's relative sluggishness compared to, say, Linux. To wit, it is great if Apple's kernel team's metrics are overall performance and not some microbenchmark. But at the end of the day, microbenchmarks can point to where the bottleneck lives—is just process creation a bear or do all system calls have awful overhead? Thus I just have to disagree with the following:
Apple's decision to measure kernel performance "from the top" by looking at the behavior of the real applications running on the full OS dictates which aspects of the kernel get the most attention.
Because poor performance "at the top" does not tell you anything about where to focus your attention; it suggests a problem and then you start drilling down, first by profiling the offending application and then likely followed by so-called microbenchmarks and other mechanisms for pinpointing the issue. Indeed, poor performance "at the top" may not even live at the kernel level—I would blame every component of the stack before I faulted the kernel for lackluster performance.
I enjoyed the discussion on OS X's equivalent of inotify:
Apple has chosen [to limit the number of filesystem events you can buffer, accepting that sometimes the buffer will fill up and you'll have to drop events]. The kernel buffers are a fixed size, and if they fill up because of a slow client, events get dropped. This means that one badly behaved client can ruin it for everyone.
Inotify suffers the same fate, as Nat's idea to make a queue overflow! t-shirt attests. At least inotify's queue size is run-time configurable. I am pleased to read here and elsewhere about Apple's fsevents and conclude that inotify is the same or superior.
I do think the idea of having an early-begot and long-running daemon arbitrate and manage filesystem events makes sense; the daemon can start earlier than, say, Beagle and continue running even after it consumes all of your available memory—joking, Shaw—asking the daemon "what did I miss?" when it starts up.