Computers, Science, Technology, Xen Virtualization, Hosting, Photography, The Internet, Geekdom And More

Stripping A File != Optimization

Posted on | February 25, 2010 | 3 Comments

It is a common misconception that the “strip” command does some kind of magic optimization to an executable resulting in it running faster. Its also a common misconception that the smaller an executable is in size, the less memory it will consume.

Neither case is correct. I could write a program in 10 lines that allocates and leaks all available memory. Stripping all symbols from  that executable (including debugging) just makes it harder for someone to figure out why that program is behaving so badly. The end result is now you have the same buggy code in a slightly smaller package, but now its much more difficult to debug.

Stripping a file is useful in two instances:

  1. You have  very limited storage space, common when discussing hand held devices. Bash’s symbol table occupies more room than any three stripped programs put together, so you would naturally want to strip them in order to make everything fit (or, compile bash differently)
  2. You  are releasing proprietary software and want to conceal what you link against, as well as the symbols you use. In this case, you often see huge statically l inked executables (bad idea) stripped to compensate for the bloat of static linkage. In this case, its just better to run the code through obfuscation prior to compiling it, then strip the symbols for good measure. You then take advantage of the same libraries already in shared memory, while hiding your already obfuscated symbols.

Stripping an executable became popular in the days where people used whatever spare parts they could to put together a “*nix box” to play with. I fondly remember a 486 DX with a 120 MB IDE drive. Just the core utils, libc and compiler tool chain would eat  that up. I remember builds failing because I would run out of disk space while compiling. I also remember the sheer hell of debugging without symbols, it was a trade off.

In this day and age, there is really no good reason for stripping executables, but I see so many makefiles doing it automatically. All it does is make things harder on the people who are actually able to squash bugs for you and send patches, while the rest of the users with 500 gig drives don’t notice that you saved them a meg or two of useful bloat.

Besides, what would your mother say if she knew you were a stripper?


3 Responses to “Stripping A File != Optimization”

  1. kalyan
    February 25th, 2010 @ 3:30 pm

    the last line is damn hilarious :P

  2. Corey Henderson
    February 26th, 2010 @ 3:00 am

    The rpmbuild utility automatically strips executable by default, except for the stuff in a -debug package. I’ll make sure I always provide a -debug package with all the binaries and libraries not stripped. That way my bandwidth is only taken up by those who wish to actively debug problems ;)

    Except for the kernel, of course, because a kernel compiled with DEBUG enabled – and not stripped – is about a GIG in size. The workspace where it was compiled is at least 10 gigs.

  3. tinkertim
    February 26th, 2010 @ 6:15 pm

    @Corey Henderson:

    Compressed, symbols take up very little room, in fact they compress as efficiently as any other text. I’ll look at bash with / without them soon and see how low both compress. But I agree, if its your own bandwidth, size might matter.

    I think were in a day and age where for most, size does not matter, hence the rant :) I’m not saying don’t do it, I’m just saying be aware of what exactly you are doing.

    I can’t count on all fingers and toes the number of people I have talked to since 2010 who believe strip helps applications use less memory. That’s just scary, considering that I was chastised for not ‘stripping’ MySQL as part of my optimization.

    “It runs better if you strip it, everyone knows that” is what they said, which is complete and utter ignorance.

Leave a Reply

  • Monkey Plus Typewriter
  • Stack Overflow

  • Me According To Ohloh

  • Meta