How can Apple trim app. sizes in OS X 10.6 without impacting features?


Recommended Posts

Mail is down to 91MB in size, whereas before it was 287MB. QuickTime is now 8MB instead of 29MB, TextEdit has been reduced from 22MB to 2MB and the Mac OS X Utility folder has dropped from 468MB to 111.6MB. Similar size reductions are reported in other OS X applications too.

http://www.techradar.com/news/computing/ap...y-so-far-498033

I am curious as to how Apple can reduce file/program sizes so much without impacting features and/or compatibility. I am guessing the above sentences are cleverly worded, and that for example, parts of the 20 MB taken from TextEdit has been incorporated into other system files etc. I understand they're trimming things here and there, but if the above is correct, that is a lot and seems unrealistic somehow, if you understand what I mean.

Link to comment
Share on other sites

Weird. On my 10.5 install:

Mail: 289mb

Quicktime Player: 31mb

TextEdit: 2mb

Utilities: 288mb

That is quite bulky, 300mb for a Mail app, none of that in 7! :) Mainly because there is no mail app out of the box :(

Link to comment
Share on other sites

http://www.techradar.com/news/computing/ap...y-so-far-498033

I am curious as to how Apple can reduce file/program sizes so much without impacting features and/or compatibility. I am guessing the above sentences are cleverly worded, and that for example, parts of the 20 MB taken from TextEdit has been incorporated into other system files etc. I understand they're trimming things here and there, but if the above is correct, that is a lot and seems unrealistic somehow, if you understand what I mean.

To me at least, apple software has always appeared 'bloated' for what it does. iTunes for example and Quicktime for another. iTunes is something like 70mb now (before install), and for something a program like winamp does in about 10% of that. That is for the windows applications, but I can only assume its the same on the apple end of things.

Link to comment
Share on other sites

To me at least, apple software has always appeared 'bloated' for what it does. iTunes for example and Quicktime for another. iTunes is something like 70mb now (before install), and for something a program like winamp does in about 10% of that. That is for the windows applications, but I can only assume its the same on the apple end of things.

Nope. Quicktime Player/iTunes/Safari are nothing like their Windows counterparts.

Link to comment
Share on other sites

Nope. Quicktime Player/iTunes/Safari are nothing like their Windows counterparts.

I bet there isn't much difference. How big are iTunes and QuickTime to download for Mac? Even if they're smaller than their Windows counterparts, it would only be because a lot of the files etc. will come included with Mac OS X.

Link to comment
Share on other sites

I bet there isn't much difference. How big are iTunes and QuickTime to download for Mac? Even if they're smaller than their Windows counterparts, it would only be because a lot of the files etc. will come included with Mac OS X.

Well yeah the frameworks and libraries that iTunes or Quicktime use are already a part of OS X. But measuring bloat solely based on file size isn't very accurate.

Open up the package contents of iTunes or Quicktimes on OS X and you'll see that the majority of the "bloat" are just localizations in the resources folder. (my screenshot above illustrates that. 261mb of international localizations, out of 289mb total file size of Mail itself)

Link to comment
Share on other sites

my guess us that a big amount of that is reduced by getting rid of localizations (all apple applications by default support all languages os x supports) and unused architectures. the application might only load the bits for the architecture being used, but the files are there to tun on PPC 32 bit, PPC 64 bit, Intel 32 and intel 64.

Snow leopard removes compatibility for PPC, so i'd say thats a 15 to 20% reduction right there.

i wouldn't be surprised if the applications now make better use of frameworks introduced in leopard such as core animation. This can potentially reduce the amount of code quite a bit.

The third thing the could be doing is simply optimizing their code to condense a few lines of coding into a single logical step.

When you put all this things together i would be more surprised than not if they couldn't get rid of 40% of the stuff in average.

Link to comment
Share on other sites

Well yeah the frameworks and libraries that iTunes or Quicktime use are already a part of OS X. But measuring bloat solely based on file size isn't very accurate.

Open up the package contents of iTunes or Quicktimes on OS X and you'll see that the majority of the "bloat" are just localizations in the resources folder. (my screenshot above illustrates that. 261mb of international localizations, out of 289mb total file size of Mail itself)

exactly, and it's not like the localization files are loaded in memory when you run the app

Link to comment
Share on other sites

Is apple removing PPC support in snow leopard (i.e. Intel CPU support only)? If so, that could be a reason why too. They wouldn't need dual binaries for the applications. Not really sure how that works though.

Link to comment
Share on other sites

If you run Monolingual you can trim much of the programs down in Leopard as is now. I run it every now and then and it helps remove a lot of the junk that I don't need.

If you run that though, make sure you exclude the Office 2008 directories else you may have to reinstall it to install any new updates MS puts out.

Link to comment
Share on other sites

I use Xslimmer, which removes the unneeded language and binary codes in order to trim down all your apps. I've gotten similar results with Mail after having Xslimmer trim it down. It seems like Snow Leopard will simply ship with just Intel binaries instead of being Universal Binaries. How else could they be doing it to save space?

Link to comment
Share on other sites

Remember snow leopard won't run on PPC Macs. All of our current software have 2 sets of instructions. One for intel, the other for PPC, since Snow Leopard will no longer support PPC, there is no point in including those code. Thus, significant decrease in file size...

Link to comment
Share on other sites

Remember snow leopard won't run on PPC Macs. All of our current software have 2 sets of instructions. One for intel, the other for PPC, since Snow Leopard will no longer support PPC, there is no point in including those code. Thus, significant decrease in file size...

No, that's not going to cause a significant reduction in size.

For proof, just strip out the PPC or i386 specific code from the applications listed and compare their size. This screenshot shows Mail.app on 10.5.6 as the normal 'fat' binary and then again with all the PowerPC resources stripped.

The reason being: the mail binary (the actual executable code) only makes up less than 6mb of the ~290mb application bundle.

The "expensive" part is the Resources folder.

As giga pointed out: in Mail every language is about 15mb worth of nib files, localized strings,

and (possibly) images.

Removing languages is the quickest/safest/easiest way to reduce the size of OS X applications.

I haven't been privy 10.6 development so while it's possible they've changed the localization

features and are just getting less redundancy "for free" but if I had to gamble I'd guess they've

just changed the installation such that only languages you enable are installed.

i wouldn't be surprised if the applications now make better use of frameworks introduced in leopard such as core animation. This can potentially reduce the amount of code quite a bit.

Not to the extent we've seen. Even if Cocoa had an NSitunes class that provided 100% of the iTunes functionality you'd only save about 20mb from the bundle. No where near the 90% reductions you can get by dropping localizations.

The third thing the could be doing is simply optimizing their code to condense a few lines of coding into a single logical step.

Not really. Any modern compiler (like say GCC that ships with XCode) is going to reduce a given algorithm to similar machine code no matter how you write it. They already perform some 'simplification' operations (ie: removing a calculation that will always return the same result from inside of loops to outside, replacing multiple instances of variables that can't change with constants, and unrolling short loops into just a a series of calls.) Some optimizations might increase the size of your binary (ie: function inlining) but it's just not significant in the scope of application bundles that are several hundred megabytes (of which binary code is less than 2%).

Link to comment
Share on other sites

@ +evn.

I think we both agree that the biggie will be localizations. The other 3 I mentioned can help but clearly not as much, which is why I listed them afterwards.

Link to comment
Share on other sites

Well it would make sense that they don't localize non-completed apps right now. It would be a loss of time.

"Hey, let's add a menu there. Let's translate it in 20 languages. Oh wait, let's remove it now"

Apple is not the kind of company to lose its time. Or well it doesn't like to.

It'd be more like

"Ok, the OS is pretty complete for us, let's send it the the translation teams and then commercialize it."

Also, I don't know if it's already like that, but instead of installing Universal binaries, the OS X DVD could say "Oh, the guy has an Intel Mac, let's install just the Intel part of the apps, no Universal binaries for nothing". This could a lot of space from what I've seen in the past.

And does anyone know if it bundles all of the OS X frameworks you asked for in XCode while it builds the app? Say, you're asking 10 frameworks. Does it build them into the app, or does it look for it in the OS X directory while the app is running? The last solution could reduce speed, but each time a new update is released, it would fix everything in every application. Or screw everything in every application.

Link to comment
Share on other sites

Well it would make sense that they don't localize non-completed apps right now. It would be a loss of time. "Hey, let's add a menu there. Let's translate it in 20 languages. Oh wait, let's remove it now" Apple is not the kind of company to lose its time. Or well it doesn't like to.

If you ever find a company where "wasting time during the development cycle" is policy: let me know so I don't accidently end up working there. More seriously, I would expect Apple has finalized the design of the menus & features long before somebody sits down to start writing / updating an application. It's standard practice in the industry and the recommended approach in their Cocoa manuals (or at least it was when project builder was still 'new hotness'). IIRC there was an introductory Interface Builder lecture where they explained "If you haven't designed the interface how do you know what features you're going to need to write to support it?"

Sadly I don't have a source for that, but you can see it in the way you use Interface Builder almost immediately after starting to code and you'll stay there until you've used it to create at least a controller and link it to a few interface elements.

Also many of the localizations and such were already complete for things like TextEdit. It'd be more work to take them all out then re-introduce them again with minor additions/subtractions than to just ignore them.

Also, I don't know if it's already like that, but instead of installing Universal binaries, the OS X DVD could say "Oh, the guy has an Intel Mac, let's install just the Intel part of the apps, no Universal binaries for nothing". This could a lot of space from what I've seen in the past.

No, that won't save anything worth mentioning. You'd be lucky to shave 200mb from a 9gb OS X installation.

In a universal application the binary is still just a single executable file (something I never really understood: Openstep stored them as seperate files, why did apple ignore that feature for binaries but keep it for everything else?)

And does anyone know if it bundles all of the OS X frameworks you asked for in XCode while it builds the app?

…Does it build them into the app, or does it look for it in the OS X directory while the app is running?

No, that's not how it works. When you compile an app linked against say Appkit - it's linked against the library. When you run the application you've compiled and the objective c run time fires up it'll run your code against the version of the library already loaded in memory. If no copy is loaded then it'll do that. Either way: every application shares a single copy of the appkit framework on disk and in memory. When you use a tool like activity viewer to look at the memory use of applications it'll report them each as though they're the only one using each of their frameworks so all of the numbers look much larger than they are (among other reasons).

A direct quote from the Framework Programming Guide is:

  • At runtime, a single copy of the library’s code is shared among all the processes using it, thus reducing memory usage and improving system performance.
source

Say, you're asking 10 frameworks. The last solution could reduce speed, but each time a new update is released, it would fix everything in every application. Or screw everything in every application.

The problem your describing is commonly refered to as DLL Hell on Windows (or Library Hell if you're from a *nix background).

Mac OS X has a number of things it does to reduce the problem of DLL hell. For example, frameworks in system:library:frameworks:xxx.framework are bundles. You can have multiple versions stored inside of the system:library:framework:xxx.framework:versions folder, and a symlink that always points to the newest versions. If your application depends on a specific version of a framework then it can load that while other's continue to use the most recent one.

There are also facilities for loosely linking against certain capabilities provided by a framework. If a given symbol isn't available but isn't tightly bound to your application it's possible to continue running without it (dynamic languages are awesome!). This would allow you to build an application that (for example) takes advantage of coreImage on Mac OS X 10.4 but doesn't crash instantly when run on 10.3.

You can find some details about this in the "weak linking" section of the document linked above. IIRC Amit Singh's "Mac OS X: A systems Approach" also discussed the runtime environment.

I think we both agree that the biggie will be localizations. The other 3 I mentioned can help but clearly not as much, which is why I listed them afterwards.

EDIT:

Yes, i thought you did. I think I'm harping on the "changes to binaries aren't going to save anything worth mentioning" because this is almost certainly driven by a desire to get old PPC mac users to buy a new machine rather than a "we can't possibly make this work elsewhere" decision.

Obviously there are good "not-greedy" reasons to drop powerpc support: like reducing development / QA time and being able to drop support for other hardware too (like certain sound/network cards for example). But it's dropping powerpc support doesn't provide any real benefit to customers. I get the feeling Apple (and irrational fans) will try and spin it that way and it's just not true.

Maybe by starting early I can stomp that line of reasoning before it gains traction.

Edited by evn.
Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.