How Snow Leopard Cut ObjC Launch Time In Half 158
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."
Re:enough fucking (Score:2, Insightful)
Considering that the whole point of Snow Leopard was to refine the internal structure of the operating system and introduce new features for developers, it should come as no surprise that there are far more /. appropriate stories about it than the more eye-candy oriented releases.
Re:I've heard that before.... (Score:3, Insightful)
Re:enough fucking (Score:5, Insightful)
Comparing this to Superfetch is ignorant beyond belief. Superfetch is part of the paging system on Windows and attempts to trigger page faults before the data is actually needed so that it's already cached when it is needed. This is quite a nice feature and one I am naturally prejudiced to like because my PhD was in this topic.
This is entirely different. Part of it is similar to the existing prebinding / prelinking stuff in Leopard / Linux, which generates the relocation tables in position-independent code. This is nothing like anything in Windows, because Windows doesn't use position-independent code for shared libraries (it uses a horribly ugly hack which performs better in the best case and much worse in the worst case). The article is a bit too light on details to understand exactly why the new version performs so much better.
The other half, however, is very clever. By caching the selector uniquing information, they are saving a lot of time when loading compilation units containing Objective-C code. Even better is the fact that, because these symbols are now not modified, they can be shared between processes without triggering copy-on-write faults. This isn't actually that hard to implement for the GNU runtime; just give the selector symbols mangled names and mark them as having common linkage (it's a bit harder on Darwin because Mach-O is weird), then you can use pointer comparison as a first step in the runtime and avoid the strcmp() call. Combining this with the prelinking support and you get the caching for free, which is very nice. I actually implemented this in Clang while writing this post, so expect to see it on non-Apple platforms soon too.
Re:Commen Sense Sharded Library (Score:4, Insightful)
Does Linux need selector uniquing if it doesn't use Objective-C?
No it doesn't. Since the average executable on linux is static code linked to dynamic libraries made up of static code, you get your "selector uniquing" at compile time - you don't get a method selector description, instead you get a pre-calculated and already unique address of the method or function.
To me this sounds like an inefficiency in Objective-C that made it less efficient than C++ (the other OO flavour of C) has been improved somewhat.
It is a tradeoff. You get to worry about the performance of shared library selector uniquing, but you get all the benefits of dynamic language and runtime. In practice such inefficiencies matter most in cases where you are very constrained for resources - e.g. on a phone, as hinted in TFA. I doubt in the context of the rest of the performance and efficiency improvements in Snow Leopard and on a reasonably modern computer, the 1/10 of a second or the few megabytes of memory saved matter all that much.
Apple made a rod for their own back with Obj-C (Score:1, Insightful)
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. Plus a lot more people would have been able to cross-code for OS/X without having to learn an obscure OO version of C which never caught on in the wider IT world and is still used on practically no other system.
Re:Apple made a rod for their own back with Obj-C (Score:1, Insightful)
Objective-C simplifies many design patterns. Some have language level support at the core. Objective-C is a very simply, elegant language. It's not hard to learn at all. In fact, compared to C++ it's down right plain. Personally, I don't want to waste my time and brain cells learning all the intricate, ass chapping c++ quirks. I'd be better devoting those brain cells to Haskell.
Re:Apple made a rod for their own back with Obj-C (Score:4, Insightful)
Right, because obviously the ultimate evolution of computer languages for all time is C and C++. There's never any need to further innovate that technology whatsoever.
Are you @#$@ kidding? It wasn't that funny.
I take issue with the assertion that nobody ever caught on with it. GNUStep? NeXT has been around for something like 15 years in industry now. EDS and others used it. Ross Perot was so impressed he invested in it and because a director at NeXT. It has a very feature rich set of frameworks associated with it, depending on your OS deployment. The only thing that sucks is Apple dropping OPENSTEP / Obj-C for Windows. But Steve didn't care about the enterprise market anymore at the time, and it might have eroded some mac hardware sales, and you couldn't very well charge a license for it. (I disagree, I think you could and can)
Re:Apple made a rod for their own back with Obj-C (Score:0, Insightful)
Right, because obviously the ultimate evolution of computer languages for all time is C and C++. There's never any need to further innovate that technology whatsoever.
Sure there is need for that. But does Objective-C do that? The GP said he doesn't think so. You should start there if you wan't to make a point.
I don't get it. (Score:2, Insightful)
Why don't they (any OS) just add something onto the generic filesystem caching layer to keep executable bits in RAM as long as the input files stay the same? If it was done that way you could theoretically reuse it for interpreted code as well.
Re:I've heard that before.... (Score:2, Insightful)
Gretchen, stop trying to make Superfetch happen. It's not going to happen.
Re:I heard of it, and USED IT, before that... apk (Score:1, Insightful)
Oh boy, its my good buddy Alexander Peter Kowalski
Why do you always have to chime in with some bizarrely formatted story completely tangential to the topic at hand?
I'm surprised you're not whining about the HOSTS file today. Boo-hoo, I can't put 0 in the HOSTS file. STFU.
Go back and write some more useless Delphi shit you crazy fuck.