How Snow Leopard Cut ObjC Launch Time In Half
MBCook writes "Greg Parker has an excellent technical article on his blog about the changes to the dynamic linker (dyld) for Objective-C that Snow Leopard uses to cut launch time in half and cut about 1/2 MB of memory per application. 'In theory, a shared library could be different every time your program is run. In practice, you get the same version of the shared libraries almost every time you run, and so does every other process on the system. The system takes advantage of this by building the dyld shared cache. The shared cache contains a copy of many system libraries, with most of dyld's linking and loading work done in advance. Every process can then share that shared cache, saving memory and launch time.' He also has a post on the new thread-local garbage collection that Snow Leopard uses for Objective-C."
I take it since then shared library machine code has had to be patched in memory after it's loaded for a while now, thus preventing easy sharing among processes, and causing the page to need its own space in the swap file.
Sounds like this latest improvement effectively brings things back to the way they were, by effectively writing this patched version back to disk so that it can be mapped read-only as before, and not have to be patched every time the library is loaded into a process. It's odd, because I thought the OS already did this several versions ago when prebinding.
It's nothing like Superfetch. Superfetch preloads applications into system memory and this shared cache doesn't do that instead from what I understand it preforms some of the work the linker would do on load in advance.
If all else fails, immortality can always be assured by spectacular error.
Me thinks you (and many other readers) are mistaking this feature for more traditional static dyld caching.
This enhancement is actually about caching a runtime computation for Objective-C purposes. In practice, as the linked article indicates, this computation is consistent most of the time. In some cases it is not. So to handle the general and most common case, these computations (selector uniquing) are cached and used across different processes.
So the fair question is does Linux cache selector-uniquing?
What impresses me significantly is that instead of concentrating on glitzy and often useless new "features," Apple actually implemented substantive performance enhancements. The import of this approach can't be praised enough in my view. Anecdotally, I recovered 6 GB of hard drive space, and immediately experienced noticeably zippier launches since yesterday's upgrade. My MacBook Air on Snow Leopard loaded on feels almost as nimble as my old IBM T-41 that operates on Ubuntu 9.04. Holy cow, this is no small thing. Just, good on them!