Apple has already announced the successor to Leopard, called Snow Leopard, during the WWDC not too long ago. They explained that Snow Leopard would not focus on user-visible features, but instead would deliver performance improvements and resource footprint reductions. One of the measures Apple has taken is the size reduction of application bundles, which has resulted in dramatic weight loss for a lot of applications. AppleInsider has found out what exactly Apple has been doing to lose that much weight.
The weight loss in Snow Leopard’s bundles is astonishing in many cases; for instance, Mail.app went from 287MB in Leopard, to just 91MB in Snow Leopard. Another good one is Image Capture, which went from a very fat 15MB to just 1MB. How exactly did Apple achieve such a weight loss?
One measure is the fact that Apple has removed the various localisation files from each application, relying on a centralised container instead from which application can draw the things they need. Another measure is the compression of Interface Builder’s NIB files; NIB files also contain the graphical resources. In addition, Apple lost weight by deleting the designable.nib files from bundles – they are the xml files used during development, and they shouldn’t be in the final builds, but due to an error by Apple, they were included anyway in Leopard’s bundles. Compressing the NIB, xml, and html files in Leopard’s mail already reduces Mail.app from 289 to 96.6MB.
While Apple may likely be expanding the use of background file compression to save space in Snow Leopard, today’s Mac OS X Leopard is unnecessarily overweight due to an error Apple made when packaging the system, according to a developer who asked to remain anonymous. Leopard apps all contain superfluous designable.nib files that should have been removed in the Golden Master. “Mail alone has around 1400 of these files, taking up almost 200 MB of disk space,” he noted.
The last important measure is resolution independence. Resolution independence relies on vector graphics, which take up less space than ordinary graphics resource files. Which brings us the final point where size reduction could benefit from, according to many – the ditching of PowerPC code from universal binaries. According to reports, this hasn’t happened yet, and it wouldn’t make much of a difference anyway.
As for the removal of PowerPC code, developers note that Snow Leopard’s applications are still currently being delivered as Universal Binaries anyway, and that removal of that extra code has a very limited impact on file size when compared to the results of compressing large XML and graphics files related to interface localization and the complete removal of any unnecessary development NIB files.
You can achieve similar results on Leopard already with tools such as MonoLingual and Northern Softworks Leopard Cache Cleaner. Deleting the designable.nib files helps too.
Looks like a lot of the use of the word “binary” in the summary is inaccurate – since it appears a large percentage of the crap removed as stuff OTHER than the actual compiled binary.
Why not use the term “bundle” as the linked article does? This seems to be a more accurate description of what is going on.
seize reduction -> size reduction
Both issues fixed. Stupid me
. Thanks!
if similar changes were made to the printer drivers – it’s ridiculous to have 2.1 gigs of printer drivers, much less a third of that being nothing but Epson.
The not removing unused elements of the library in the linker would explain a lot about the heft of OSX. Given that the applications on the whole tend to be self contained packaging all elements of a library, even those that are unused would indeed be unneccessary bloat – but an easy thing for a programmer who doesn’t even understand what a linker IS to miss.
Edited 2008-06-28 00:13 UTC
Just to be clear about one idea flying around recently.
Applications bundles on OS X DO NOT duplicate any system libraries (more generally called framework), absolutely not. If an application needs to have its custom frameworks then it does put in its bundle, but the system framework are not duplicated in the bundles.
What do yo mean unused elements of the library? Which library?
Frameworks are dynamically linked to the executable, they are not added to the executable. So what’s your point?
What do you packaging all elements of a library?
Again frameworks are contained in one location /System/Library/Frameworks
there is no packaging or whatsoever. Again, besides its custom frameworks, an application bundle does not contain any other duplication of the system frameworks.
What are NIB files but a library file included at packaging? How is the packaging process any different from a linker when it comes to condensing a bunch of separate files into the same ‘file’ – it’s the same concept. (Closest comparison windows side would be a resource file or set of resource files compiled to a DLL)
Including unused NIB’s in the package is the same as including unused DLL’s in a .msi or compiling unused libraries into an executable.
That they are packaged into the same distributable ‘file’ though means it could incur slowdowns, as package files are basically handled as a filesystem and it’s more files to wade through trying to get to the ones that are actually being used. The slowdowns from this could be compared to the old interpreted BASIC days where you could speed up some programs and make them practical to exchange at 150 baud just by deleting a few REM statements and trimming unused subroutines – stuff that was/is good during development but has no place in a distribution.
Edited 2008-06-28 08:29 UTC
WTF?! I was using Monolingual (thanks for reminding me btw, I already had it but forgot about it) and was removing languages and they had an entry for klingon. Do they seriously have an entry fo klingon? How pathetic do you have to be to learn a fictional language and use it on your machine daily. Do they have all of the Lord of The Rings languages as well?
And you thought geeks only used Linux, eh?
Support for Klingon in Mac OS makes perfect sense. Historical sense. Read:
http://lowendmac.com/orchard/05/star-trek-mac-os-intel.html
How pathetic do you have to be to whine about “weird” languages being implemented? What does it matter? Some people like learning other languages. Even if they aren’t in wide use.
I know my apps the binaries are very small. However to make it look just right I use a lot of high resolution graphics. Lossy compression only makes it look bad. So I put the lossless high resolution graphics. Sure it takes up space but it makes my customers happy, and my customers pay the bills. There are rumors that Apple are going to use Video hardware acceleration to the next level Vector Graphics 2.0 which could account for a good file saving.
Xslimmer works really well. It’s $13 US but it’s worth it. Takes out all the extra junk like languages you don’t need and also makes all apps processor specific.
So if you are on an Intel Mac you don’t need any code for PPC. Xslimmer will remove all that from almost all applications.
Made everything on my white Imac (In Leopard) work much faster. (Apps start faster and it freed up like 2 GB of space)
Apps starting faster after slimming is a myth. (A placebo effect more accurately) The unused resources are exactly that, unused to begin with.
It may be a placebo effect but from my personal experience before I slimmed apps on my computer most apps on leopard would have that stupid blinking light that would blink on the dock 5 or six times before the app would open.
Now most apps are one or two blinks and they are up and running.
Long as my mind is happy with it, I am good to go. LOL!
A myth?? Xslimmer works very well and does speed things up on my MacBook. Loading FireFox, iTune, Entourage is much faster after slimming them down.
The OS feel snappyer now than it was before.
I feel sorry for the Xslimmer devs, I wonder if this app will still have it’s place with Snow Leopard.
Definitely not, if apple is really serious about optimization then it is definiteyl going the route of doing the easier tasks first. Which means stripping out the unneeded code and adding something similar for third party apps.
Yeah, and the thing is, XSlimmer really does reduce apps by about half their size *by getting rid of the PPC part*. However, this only seems to be the case for certain apps, mostly non-Apple ones. Maybe the added size for PPC binaries is a lot bigger for Carbon apps than for Cocoa.
When using Xslimmer on my mac it worked just as well on universal Apple apps just as well as on non Apple Apps.
For instance on Quick time 7.4.5 It was 29.1 MB and it was slimmed down to 7.23 MB
For Safari 3.1.1 Was 65.7 MB now it’s 7.59 MB
For Address Book was 58.2 MB but now it’s 4.46 MB
For IMovie it was 119 MB now it’s 60.5 MB
For Iphoto it was 211 MB now its 82.3 MB
For Itunes it was 137 MB now its 34.4 MB
So my Apple apps seemed to of slimmed down pretty good.
The reduction comes mainly from localization packages being stripped.
The executable is already small and dynamically loads the localization package configured from your System Settings.
That is true. It also strips out any PPC code.
The real change will be when much of Apple’s design around their bundles and interaction with various level of frameworks adjust for Cocoa versions of their flagship applications and standard OS applications.
Being a NeXT Alum, OS X 10.6 is the first release that will be what we discussed in 1997/98–Cocoa OS X.
Too bad it only took a decade to silence the Mac faithful who wouldn’t have an OS today to cling to if it weren’t for the merger.
So they’re finally going to FTFF (Fix the… “frustrating” Finder)?
You know, for a company that prides itself on “hardware hardware hardware”, Apple sure knows how to dip it’s collective feet in the software racket. Is Ballmer giving tips to Jobs?
This release is nothing more than OS optimizations that should have been done at the time Leopard was released, or at some point along the life cycle. It’s hardly a major rev that requires a $129 expenditure from even the most zealous of fanboys.
If there is nothing earthshattering about a relase then just don’t buy it. It’s a minor release after all.
I can only applaud that someone is actually working on reducing the footprint of the operating system (incl. applications).
There are going to be a lot more changes other then slimming down apps.
Most of the slimming of apps are the fact that it seems Snow Leopard is going to be Intel only anyway.
But there are a lot more underling changed being made to security, and almost all the underlying technology.
I think that 129 is a little pricy though.
So use Linux if you have an aversion to paying for software. Or just stick with the version you are currently using if it works?
All software upgrades are incremental. That’s the nature of *any* product development. You get one huge revolutionary upgrade once every so often, and then the subsequent upgrades are all incremental evolutionary ones. Look at cars (lol, another car analogy). All Fords should be free, since everything they’re bringing out should have been in the original model T anyway.
“This release is nothing more than OS optimizations that should have been done at the time Leopard was released, or at some point along the life cycle. It’s hardly a major rev that requires a $129 expenditure from even the most zealous of fanboys.”
I am glad Apple figured this one out. I’ve been using Xslimmer, deleting useless font families, adding the Liberation font family and performing other minor things which annoy me.
“So use Linux if you have an aversion to paying for software. Or just stick with the version you are currently using if it works?
I use open or free more-often-than-not and pay a programmer when their software is excellent. Either way, I am contributing to both to free choice and a free market.
Good lord the Microsoft animation on this page is annoying as hell.
Edited 2008-06-28 17:36 UTC
Ok, then explain to me what technology is so new in 10.6 that warrants the pricetag? They’re deleting fonts, drivers, and removing backwards compatibility with PPC. I’d say that makes a nice 10.5.6, but not 10.6. Maybe they’ve got some other newfangled software tech up their sleeves….who knows. All I’m saying is the list of “changes” reads like a Windows service pack, as it stands today.
Wait, did I miss where Apple released the price of 10.6? I’m not saying they won’t charge $129 for it, but it’s also possible that they may offer it at a reduced cost to those that already purchased Leopard (maybe those software update coupons will be useful for once). I guess we’ll know more at MacWorld in January.
Somehow this strikes me as very funny, seeing the savings that are coming from compressing the XML files. The only difference between a Z/gz/bz2 xml file and a binary config is that you might be able to unzip and human-parse the former. Next thing you know, they’ll be using ODF!
Whitespace is a bitch.
🙂
Maybe they’ll be using a “Binary XML” format, which is fast and easily parsable, as well as being able to be transparently opened and edited by XML editors (provided they support the file format).
http://en.wikipedia.org/wiki/Efficient_XML_Interchange
That looks pretty cool, actually, and I wouldn’t put it beyond Apple to use something that isn’t necessarily a fully developed standard in their products. At the same time, Occam says they just compressed the existing formats.
Still, this issue is something I’ve been thinking about lately, having had to dig more into Active Directory GPOs on a project I’m tasked to at work. While I had always viewed the Windows registry as just an annoyance in the past, when I had to modify a policy that was a stored registry value, the speed of parsing became very apparent to me. My colleague, who doesn’t have any programming background beyond VB, couldn’t wrap his head around why there was one registry value for a bunch of different things. It’s like, it’s a lot easier and quicker to parse if it’s one binary value! 🙂
Convert human-readable (and editable) configuration files into a proprietary binary format and call it a feature…
Seriously, while the ability to only install the localizations and platform binaries needed on your machine would be nice (and, as I recall from playing with NeXT in VMware, was a feature present in the pre-Mac versions of the OS) the amount of space savings gained from moving from human-readable (and modifiable) plists to binary ones is SO minimal thatI suspect the real reason their doing so is to make life harder for the OSX86 crowd, who often have to edit the plists of control panels and drivers in order to get stuff working on their frankenboxen.
millions of config files spreaded in linux file system is the worst solution. A central database is better.
Edited 2008-06-30 06:47 UTC
You can convert between XML and binary using plutil or edit them by using Property List Editor.app or defaults.
$ plutil -convert xml1 ~/Library/Preferences/com.apple.dock.plist
Any news on ZFS for Snow Leopard? That would just be the Cherry On top of the whole thing.. and make it worth it..
Snow Leopard server will have ZFS! I assume that it isn’t going to be in Snow Leopard client, however.