Thinning universal binaries with ditto
SoftwareIn November of 2006 I uploaded a post called A Closer Look At Apple’s Universal Binaries where I tried to describe what UB's are and how to use the lipo
command in the Terminal to remove unnecessary code. Since then I've learned a bit more, and have found a slightly easier way to do it.
Previous post in a nutshell: If you've used Mac computers at all since 2005 you're probably aware of Universal binaries, the fancy name Apple gave to applications that have native code for PowerPC and Intel processors. While they really simplify distribution, they store code on your machine you don't actually need.
Fortunately in Tiger Apple bundled the ditto
(and lipo
) utility which you can use to create a thin
version of a universal binary that only contains code for your processor.
TAKE NOTE! Some older applications that are only compiled for PowerPC CPUs require shared libraries or resources from other applications, some of which may have been updated as Universal. Therefore if you start deleting PowerPC code from them, you may start braking things. If you're not sure, always keep the original universal binary just in case you need to restore it!
ditto --arch i386 FooBar.app ThinFooBar.app ditto --arch ppc FooBar.app ThinFooBar.app
The first line thins down FooBar.app
to include only i386 code, the second preserves only PowerPC code.
The use of an unnecessarily long sword to spit universal binaries is not recommended… unless you're a flame haze… I'm sorry, but I can't stand dry weblog posts that don't have pictures. The thought of weblog posts without pictures keep me awake at night, as I'm sure it does for you too.
Given my current obsession with tables, below is a selection of my favourite Mac open source applications I thinned down on my MacBook Pro to compare the difference between their universal and thin binaries:
Application | Version | Fat universal | Thin i386 | % original | % saved ↓ | |
---|---|---|---|---|---|---|
![]() |
VLC | 0.8.6c | 75.2 MiB | 43.1 MiB | 57.31 | 42.69 |
![]() |
Camino | 1.5.1int | 53.7 MiB | 34.2 MiB | 63.69 | 36.31 |
![]() |
Inkscape | 0.45.1 | 84.1 MiB | 56.4 MiB | 67.06 | 32.94 |
![]() |
iTerm | 0.9.5.x | 4.1 MiB | 3.2 MiB | 78.05 | 21.95 |
![]() |
Gimpshop | 2.2.11 | 191.0 MiB | 149.3 MiB | 78.17 | 21.83 |
![]() |
Smultron | 3.1 | 10.1 MiB | 9.4 MiB | 93.06 | 6.94 |
And here's a similar table looking at bundled Apple applications:
Application | Version | Fat universal | Thin i386 | % original | % saved ↓ | |
---|---|---|---|---|---|---|
![]() |
Safari | 3.0b3 | 6.5 MiB | 5.1 MiB | 78.46 | 21.54 |
![]() |
iTunes | 7.4.1 | 113.0 MiB | 98.8 MiB | 87.43 | 12.57 |
![]() |
Terminal | 1.5 | 5.0 MiB | 4.6 MiB | 92.00 | 8.00 |
![]() |
TextEdit | 1.4 | 2.2 MiB | 2.1 MiB | 95.45 | 4.55 |
Some pretty interesting results, the most noticeable of which I would think is that none of the applications even approached a 50% reduction in file size by removing half their compiled instructions. This is due to applications having shared resources such as images, text files and whatnot that are used by both the PPC and Intel code.
In this case, we can see that VLC, Camino and Safari had a sizable amount of specialised code, whereas the bulk of the TextEdit and Smultron applications consisted of shared resources. We can infer just by looking at these results that rendering video and webpages require more processor specific instructions compared to, say, a text editor.
Plus it gave me the chance to show some Mac icons. I use KDE on FreeBSD and NetBSD and have used all the flavours of Windows at some point, and the Mac is still the prettiest ;).