Xslimmer 1.7

[Quillz]

As someone who has used Xslimmer before, we thought you might be interested to know that Xslimmer 1.7 is now available, and it includes full support for Snow Leopard!

Xslimmer 1.7 supports 64-bit binaries, honors code signing rules, is able to handle and create native HFS-compressed files and adds many other improvements that will continue to provide a worthwhile and reliable experience to Snow Leopard users, as well as to all other users that choose not to upgrade to the latest OS yet. Read on for the gory details! Universal Binaries are so 2008, aren't they?

Well, unfortunately they are not. Or, should we say, fortunately they are not. Universal Binaries were a key technology that allowed Apple to transition from PowerPC to Intel CPUs in the most awesomely flawless technology adoption ever. The same Universal (or, as they are affectionately called, "fat") Binaries are being put to work again to ensure that Snow Leopard and its apps run flawlessly in all compatible Intel machines, including 32-bit and 64-bit ones.

So instead of packaging binaries in a bundle that contains PowerPC and Intel versions of the code, it will now become usual for developers to provide the 32-bit and the 64-bit versions of the same code. The 64-bit version will be used in 64-bit computers, whereas the 32-bit code will run in CPUs that are not able to handle 64 bits. There is no magic way for the system to transform one into the other, so no matter what computer you have, chances are many of the apps you install will contain code that will be ignored and never will run.

But it gets more interesting! Snow Leopard is truly awesome, but there is no reason for developers not to support Leopard if they can. True, some apps will take advantage of Snow Leopard exclusive technologies such as Grand Central Dispatch, OpenCL or some other new APIs; however, many others won't need these innovations yet and will still support Leopard. But Leopard does run on PowerPC machines, so developers should include a PowerPC version of the code if they want to support the same hardware requirements as the OS. As a result, we are starting to see applications that include not two, but three architectures: Intel 32, Intel 64 and PowerPC. This is the case for some very popular apps such as Tweetie for Mac or the latest version of Apple's own Airport Utility.

Xslimmer was designed to handle these situations, and it has now been tested and optimized for the scenarios above so it will always keep the best version of the code that is available for your Mac. If you own a 64-bit-ready Mac, then Xslimmer will preserve the 64-bit version of your applications' code - when it's available. Won't Xslimmer break 64-bit applications? What about code-signing?

As discussed above, Xslimmer carefully analyzes your applications and selects the best possible architecture among those available. This is done in a per-application basis, and not following some batch process that blindly keeps a single combination. Analysis includes evaluation of signed resources: code-signing rules are fully honored so that only binaries that can be safely modified will be processed.

Extreme care is applied when slimming, and the operation is performed in the most friendly way. Your slimmed applications are registered again for you in the internal OS databases - your keychain authorizations are preserved, and you don't even need to restart your Mac after slimming it. But Apple applications are already compressed!

Snow Leopard achieves significant space savings by using transparent file system compression. In fact, all system applications and utilities are installed in a compressed state, although they are transparently uncompressed on the fly without the user ever noticing. Xslimmer 1.7 recognizes and supports this type of compression: if a compressed application is slimmed, then it will be recompressed automatically. Therefore, all system applications in Snow Leopard will still benefit from additional space savings if they are slimmed, without affecting their compression status.

When running on Snow Leopard, Xslimmer will always show you the actual size your applications take up in your disk, and not the uncompressed size as reported by Finder and other tools. This way you can be absolutely sure about the savings you achieve.

We have even taken this technology a step forward. A new option in Xslimmer 1.7 will allow you to compress slimmed binaries that were not originally compressed. This way, your installed third party apps can also benefit from this awesome new technology in Snow Leopard. Ok, I'm sold - I'll give it a try!

Wonderful! We've always worked hard to prove that your choice of Xslimmer is really the best option for your slimming needs. In Xslimmer 1.7 you'll find many features designed to slim your Mac easily and with total peace of mind. These include:

• Strip out unneeded localizations - As usual, Xslimmer 1.7 will remove translations you don't need, achieving great space savings.
  
• Visual indication of architectures - Another new feature in Xslimmer 1.7, you can now see what architectures an app contains and what the resulting architecture is: Intel 32, Intel 64, PowerPC 32 or PowerPC 64.
  
• Downloadable blacklist - for those apps that check themselves (for anti-piracy reasons, usually) and refuse to start after they have been slimmed. We test every report from other users about malfunctioning apps.
  
• Your personal exclusion list - for folders in your disk that you don't ever want to mess with, for whatever reason.
  
• Integrated backups - designed to let you test your slimmed apps with the confidence that you'll be able to recover them in one click.
  
• Extreme compatibility - Xslimmer 1.7 has been fully optimized for Snow Leopard, but it will still run in Panther, Tiger and Leopard.
  

So, no matter whether you are a longtime Xslimmer fan or have come across it recently, now is an excellent time to check the combined space savings that Snow Leopard and Xslimmer will bring. We hope you like Xslimmer 1.7!

Xslimmer

[AltecXP]

I plan to run this soon as I get a fresh install and see how much more space I get back.

[what]

Saved 2GB from 85 applications. Nice.

[cabron]

Saved 2GB from 85 applications. Nice.

Yup, its a nice app, it saved me a lot of space.

[Phantom Helix]

i really hate to ask this question, but

since SL now is counting base 10's so a 2gb drive is actually showing as 2gb, and since the system applications and utilities are on the drive in a compressed state (presumably reflected in a smaller footprint in finder) but Xslimmer is showing you the uncompressed size, is it showing you the base 10 calculation of space saved or base 2 when it reports after job completion? and is it including system file savings in compressed or uncompressed size at final report?

and if it is not following base 10 like SL what is the comparison of its report to finders on disk before and after slimming?

[.Neo]

Does this still screw up certain application (suites) like Microsoft Office and Adobe Creative Suite?

I can see this being a nifty tool on a MacBook (Air) or Mac mini, but with a 640 GB Macintosh HD I don't really care about reclaiming 1 or 2 GBs. :p

[cabron]

I can see this being a nifty tool on a MacBook (Air) or Mac mini, but with a 640 GB Macintosh HD I don't really care about reclaiming 1 or 2 GBs. :p

I have as well a 640 GB, but Xslimmer not just recover disk space but also performance. Mail default app in Leopard is close to 200MB, with Xslimmer Mail went down to 24.7MB. Now Mail start more faster than before.

Edited August 30, 2009 by cabron

[the evn show]

I have as well a 640 GB, but Xslimmer not just recover disk space but also performance, Mail default app in Leopard is close to 200MB, with Xslimmer Mail went down to 24.7MB. Now Mail start more faster than before.

That's placebo effect.

in 10.5 the majority of Mail's girth is the designable nibs in all of the language translations. Designable nibs aren't loaded by the application and play no role in launch speed. Further, of all the nibs translations that can be removed: only one set is ever loaded by the application, that's true whether the bundle contains 30 language translations or just one.

Stripping architectures from the binary will also have no perceptible impact on performance.

The loading process for a universal binary is as follows (simplified for the sake of illustration)

1. The OS says "hey the user wants to start mail"
   
2. The application launcher heads over to mail.app and sees that it's a bundle
   
3. The launcher heads into the bundle to /content/macos/ and opens a handle to the mail binary
   
4. The launcher memory maps the file.
   
5. The launcher reads the header of the mail binary. it looks like this:
   

   Mach-O executable.
   Universal Binary: 2 architectures.
     1. PPC: 128 bytes, 1002 bytes
     2. i386: 1131 bytes, 1100 bytes

   
   

6. The launcher looks at the binary header and sees that it's a mach-o executable (if it wasn't a kind of file OS X can run, it'd throw an exception).
   
7. The launcher reads the list of universal binary architectures: The first digit tells it where the start of the PowerPC binary is, the second tells it where the start of the i386 binary is.
   
8. the launcher seeks to the appropriate starting offset for your architecture and reads the appropriate length of code.
   
9. The code is handed to the the Objective C runtime and the whole thing starts to loading process starts.
   

None of those steps can be skipped when loading the binary: even with one architecture the launcher still has to check the header for executable type and code-offset info. Even if there were thousands of architectures in a binary the check happens so fast that no human being could measure it (Millionths of a second).

The loading process once we're into the objective C runtime is going to be identical so there's not much worth talking about.

[.Neo]

That's placebo effect.

That's what I was thinking. I never experienced any noticeable speed improvements after applying XSlimmer in the past, so I just stopped using it.

[Quillz]

That's what I was thinking. I never experienced any noticeable speed improvements after applying XSlimmer in the past, so I just stopped using it.

I'm pretty sure Xslimmer isn't about speed improvements but space improvements. At least, I never used it in the hopes of making my system faster, I used it in the hopes of saving a gig or two of disk space.

[the evn show]

I'm pretty sure Xslimmer isn't about speed improvements but space improvements. At least, I never used it in the hopes of making my system faster, I used it in the hopes of saving a gig or two of disk space.

That's it: and that's not to say there's anything bad about that. If you have a small hard drive (older hardware or an SSD drive) then there's a lot to be said about nabbing a few gigabytes or even just a couple hundred megabytes back.

Not every improvement has to be about making something quicker: sometimes plain old 'smaller' is better, and other times it's worth trading performance for stability, compatibility, or ease of use.

[+John. Subscriber¹]

Saw this as soon as it hit VersionTracker. Good update to a very useful program.

[.Neo]

I'm pretty sure Xslimmer isn't about speed improvements but space improvements. At least, I never used it in the hopes of making my system faster, I used it in the hopes of saving a gig or two of disk space.

cabron claimed Xslimmer also improved performance of its applications, something I seriously doubt. I don't really need to save a GB or two so that's why I stopped using it.

[Ricardo Gil]

Are we in a day and age where this kind of application is still needed? I don't think saving 2 or 3 GB of space is that useful given the huge hard drives we use today.

[.Neo]

Are we in a day and age where this kind of application is still needed? I don't think saving 2 or 3 GB of space is that useful given the huge hard drives we use today.

Like I said before, personally I don't need it considering the fact I have a 640 GB Macintosh HD with room for 3 more internal drives. However, I imagine that some people like MacBook Air and Mac mini owners welcome this application.

[+John. Subscriber¹]

Like I said before, personally I don't need it considering the fact I have a 640 GB Macintosh HD with room for 3 more internal drives. However, I imagine that some people like MacBook Air and Mac mini owners welcome this application.

With the amount of content I have on my unibody MacBook, I find it pretty useful as well.

[Ricardo Gil]

Like I said before, personally I don't need it considering the fact I have a 640 GB Macintosh HD with room for 3 more internal drives. However, I imagine that some people like MacBook Air and Mac mini owners welcome this application.

Just a curiosity:

A topic about saving a few gigabytes with an "8 terabyte upgrade" topic just above :laugh:

[.Neo]

Haha good one. :laugh:

With the amount of content I have on my unibody MacBook, I find it pretty useful as well.

Hence the word "like". Didn't feel like pointing out every Mac model out there that might benefit from this. ;)

[Quillz]

Are we in a day and age where this kind of application is still needed? I don't think saving 2 or 3 GB of space is that useful given the huge hard drives we use today.

Not everyone has "huge hard drives," so any space that can be saved adds up quickly.

[what]

I can fit a lot of useful things in 2GB of space. Why would I want to waste it on binaries that are never going to be used?

[sanctified Veteran]

Are we in a day and age where this kind of application is still needed? I don't think saving 2 or 3 GB of space is that useful given the huge hard drives we use today.

Try to be a budget art student, every byte counts ;)

[LightIdea]

I use this also to free space, not to gain performance, I don't think you can gain even the slightest 0.1% increase in performance after using that utility.

[PyX]

Well saving 1-2GB might be silly, but it's still optimization - pretty much the goal of Snow Leopard :)

So this app works hand-to-hand with the new OS.

I've never used it though. I'm just scared of, you know, breaking things...

But I think in OS X, it pretty much looks like :

/Application/

/Application/Intel 64-bit/

/Application/Intel 32-bit/

/Application/PowerPC/

/Application/Ressources/

/Application/Languages/LanguageName

So they are all totally independant from each other... I guess I CAN'T break things. (Am I right?)

Maybe it's just the fear of not leaving it as default... Dunno.

[the evn show]

Try to be a budget art student, every byte counts ;)

I have a 128GB SSD drive collecting dust (well, its in an external enclosure) because I can't find a way to fit a "useful" amount of my life into less than 160 GB so I can't use it in my notebook. For somebody closer to the edge 1-2gb could be a big deal.

So they are all totally independant from each other... I guess I CAN'T break things. (Am I right?)

For the most part architectures are fully independent. Some applications may complain (ie: Office applications check to see if they've been modified and refuse to run) but it's "reasonably" safe as far as this sort of thing goes.

Disclaimer I don't use this program, but I have written something similar (which I also don't use).

[sanctified Veteran]

I have a 128GB SSD drive collecting dust (well, its in an external enclosure) because I can't find a way to fit a "useful" amount of my life into less than 160 GB so I can't use it in my notebook. For somebody closer to the edge 1-2gb could be a big deal.

Interested in selling perhaps?