X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com Message-ID: <472EB7C8.8000600@iki.fi> Date: Mon, 05 Nov 2007 08:27:20 +0200 From: Andris Pavenis User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: djgpp AT delorie DOT com Subject: Re: Why "upx --brute" might be a bad idea... References: <4728e78c$0$16659$9b4e6d93 AT newsspool3 DOT arcor-online DOT net> <472A847C DOT 8030008 AT zytor DOT com> In-Reply-To: <472A847C.8030008@zytor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X--MailScanner-Information: Please contact the ISP for more information X--MailScanner: Found to be clean X--MailScanner-From: andris DOT pavenis AT iki DOT fi X-Spam-Status: No Reply-To: djgpp AT delorie DOT com H. Peter Anvin wrote: > Robert Riebisch wrote: >> Hi! >> >> Please read this thread at >> , how UPXed >> binaries cause compile slowdowns. >> > > "upx --brute" and "upx --ultra-brute" runs a bunch of algorithms, and > picks the smallest one, which may or may not be LZMA. I don't know how > they affect decompression speed, and it would be interesting to find out. > > In particular, the NASM build robot > (ftp://ftp.zytor.com/pub/nasm/snapshots/) appear to generate marginally > smaller binaries with --[ultra-]brute than with --lzma --best, and I'm > wondering where the difference comes from. It would also be nice to > know what algorithm it ends up using so I can tell it to use the same > one every time, instead of trying them all every time taking time (a > whopping minute every night ;) After all that I read in this thread I'm no more sure that using --lzma or UPX is a good idea at all for compressing NASM or any applications which may be executed many times and often. So GCC (so I should stop using UPX at all), binutils, NASM, fileutils etc. fits in this category for which UPX should not be used by default (of course it is users right to compress them later). Other group is applications are not expected to be executed oftem and many times from shell script, Makefile etc. Some examples GDB, EMACS, RHIDE (isn't the latest already dead?). In this case single time slowdown is more likely to remain unnoticed. As result UPX could be used (even in LZMA mode) for these executables. Andris PS. Did some tests: running compiling C language "Hello World" style program 10 times from shell script. I saw noticeable slowdown if used executables (GCC, etc) are compressed with UPX (especially LZMA). And the slowdown for compiling 10 times the same program were in worst case (LZMA) several seconds (about 3) CPU time on 2.4GHz Intel Core 2 Quad processor (WinXP SP2). Also NRV compressed GCC executables caused slowdown.