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 thought this was the shared libs always worked

[noidentity]

I thought one of the points of shared libraries was that the files could simply be mapped read-only into the memory of each process and executed directly. This would only require one physical copy in memory, even though it may exist at multiple logical addresses.

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 [wikipedia.org].

Re:I've heard that before....

[CharlyFoxtrot]

It's nothing like Superfetch. Superfetch preloads applications into system memory [microsoft.com] 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.

Doesn't sound like this is loading apps.

[Shag]

Sounds like they've just updated their dynamic (shared) library loader to be able to handle Objective C (aka Cocoa) instead of just plain C, and to be a little smarter about keeping track of what it's already got going on, so it doesn't duplicate things.

As a long-time UNIX and Linux (and other more esoteric OSes) geek, this alone doesn't impress me too much. The idea that they went through the whole OS and worked to get little efficiency/performance gains like this all over the place impresses me a little more.

Re:Commen Sense Sharded Library

[Anonymous Coward]

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?

Re:Doesn't sound like this is loading apps.

[INT_QRK]

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!

ObjC is a modern, rich platform

[SuperKendall]

Perhaps Obj-C has a few nice features but personally I don't see it. If they'd stuck to C or C++ like every other version of Unix then this would never have been an issue in the first place.

But you can use either of those perfectly well mixed with ObjC calls.

ObjC is a relatively small set of additions to standard-C, so it really doesn't take that long to pick up the syntax changes if you've encountered C before, while at the same time it allows for some very nice dynamic behavior and things like introspection. The language has evolved to support things like garbage collection (though that specific feature is not available on the iPhone due to performance constraints).

What you are really overlooking though is that Objective-C that Apple uses, has a very rich and diverse set of foundation classes (some inherited from the NeXT days) - just as wide in scope as Java. Any modern language simply has to have a giant toolbox to help get common tasks done, and that's going to be the thing that takes the most time to learn. Happily, Objective-C has a fairly consistent set of tools and conventions, that make learning new parts easier once you have learned a few others.

Re:I thought this was the shared libs always worke

[Anonymous Coward]

Shared libraries on most platforms (mac,linux,windows..etc) are "shared" within a single processes memory space only. They are NOT "shared" between processes. Each separate process instantiates libraries separatly.

I'm not so sure about that. Typically, code in shared libraries is re-entrant and code pages are loaded once, then mapped into the address space of the process using them. I don't know of any modern OS that wastefully makes a copy of the library's code for each process.