Forgot your password?
typodupeerror
OS X Programming

How Snow Leopard Cut ObjC Launch Time In Half 158

Posted by Soulskill
from the paring-down dept.
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."
This discussion has been archived. No new comments can be posted.

How Snow Leopard Cut ObjC Launch Time In Half

Comments Filter:
  • by noidentity (188756) on Sunday September 06, 2009 @10:43AM (#29331333)
    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].

    • by Anonymous Coward

      The shared libs are shared. What was not shared before is the linking table, that must be built for accessing that shared code. prelink precalculates that table, and this apple thing does more or less the same.

  • dyld (Score:5, Funny)

    by DoofusOfDeath (636671) on Sunday September 06, 2009 @11:04AM (#29331465)

    dyld - noun. A reminder that regardless of age, you'll always have an adolescent sense of humor.

  • I do not wish to be a poo poo, but since dynamic libraries and shared libraries have been around for just about forever, when even a second year CS major would immediately notice this could be done, is such big news now?

    The first thing I would have done is built a cache for the library system. LINUX has one, why not the Mac?

    So certainly I congratulate the Mac community. But wow, DUH, a cache for the linkage editor. :-)

    -Hack

    • Re: (Score:3, Interesting)

      by 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?

      • by keean (824435)
        Does Linux need selector uniquing if it doesn't use Objective-C? 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.
        • by lurch_mojoff (867210) on Sunday September 06, 2009 @12:44PM (#29332197)

          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.

          • by keean (824435)
            Makes sense... but I am not sold on the benefits of a dynamic language... how is this better than dynamically loaded shared libraries? If you really need a dynamic framework there is always XPCOM, which gives you the added benefit of being able to use it from many different languages, and of course the dynamic binding is built into Javascript which makes it ideal for linking together components written in C++.
            • The article on Arstechnica about Snow Leopard goes into some detail about the advantages of Obj-C being a dynamic language... primarily due to the new inclusion of Closures aka functions assigned to variables so that you can pass a function to another function with dynamic arguments.

              This makes for not necessarily a better performing language but an easier, more efficient and less buggy language.

              It's still likely a personal coding preference of course.

  • 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: (Score:1, Insightful)

      by Anonymous Coward

      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.

    • by mgbastard (612419) on Sunday September 06, 2009 @01:46PM (#29332677)

      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)

      • by ari_j (90255)
        Not just that, but the expense of rewriting Openstep in C++ would have been ridiculous and likely would have put Apple out of business. They did the right thing, both in business terms and in technological terms. Instead of wasting time reinventing the wheel, they just got on the cart and started rolling forward. Obj-C is also not a bad language, all things considered.
      • by am 2k (217885)

        Considering what Apple did to WebObjects, my guess is that not even charging for it would have changed that decision.

      • by fnj (64210)

        The only thing that sucks is Apple dropping OPENSTEP / Obj-C for Windows.

        What in God's name are you talking about?

        • by tim1724 (28482) *

          The only thing that sucks is Apple dropping OPENSTEP / Obj-C for Windows.

          What in God's name are you talking about?

          Back when Apple's aquisition of NeXT was first announced, Apple had indicated that they'd continue to support OPENSTEP Enterprise (the Windows implementation of OpenStep). But it was killed off pretty quick.

          • by fnj (64210)

            Thank you. I understand. As many times as I read the sentence I kept interpreting it as "dropping OPENSTEP / Obj-C for [i.e. in favor of] Windows." Was that before or after M$ dropped a bunch of dollar bills on Apple?

        • You could cross-compile code for Windows and Next Machines in NeXT's version of X-Code back in the day.
    • 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 introspecti

    • by Ma8thew (861741)
      The issue of learning the language doesn't seem to have held back iPhone development.
      • by bar-agent (698856)

        The issue of learning the language doesn't seem to have held back iPhone development.

        Yeah, Viol8. Quit slacking off, roll up your sleeves, and get going. You're behind the curve.

    • by GrahamCox (741991)
      You personally don't see it. So? Try actually using it, maybe? The advantages of Obj-C over C/C++ are so manifold that the only way to appreciate it is to code in it. A list of features won't relay much if you don't try it. I used to think C++ would be all I'd ever need, but then I got into Obj-C and my productivity went through the roof. I could never go back now. In fact I don't know how to even express myself in C++ for the kinds of concept I can take for granted in Obj-C.
  • I don't get it. (Score:2, Insightful)

    by Ant P. (974313)

    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.

  • They probably just rolled in the 2.6.31 kernel.

  • Using OS X/Mac since 10.2.8, I haven't seen another abused tool like "update_prebinding" even while it is a very risky process in pre 10.5 systems since it deals with actual binary headers.

    Also thanks to uninformed IT blogs etc, people always considered prebinding a thing which will go away in next release. Like, Apple is really stupid to do such thing. They basically misunderstood the added flexibility to prebinding scheme where tools without (or broken) prebinding will continue to run.

    Anyway, want to see

1 + 1 = 3, for large values of 1.

Working...