Enabling UPX in portage via USE, would this be possible, and if so would anyone help me implement this for a future portage release?
in what areas would you find this to be best applied ?
I dont think that this is a very good idea. It would save harddisk space, but it might introduce a lot of problems: As far as I know how executable packers like upx work, it would need more memory. Also, I don't think that upx is compatible with all programs. If you wanna save diskspace, set your CFLAGS to "-Os" (optimize for size). If oyu really want to implement something like this, also think about the script-packer gzexe, which usually can pack better than upx.
I had a rethinking, the USE flag might not such a good idea - UPX should be an ON/OFF switch, and we don't really have a way of locking a flag down. So Implementing this might be a bit hard. Anyways, the reason I wanted to implement this was that it had been stated in the thread on the forums that UPX has an extremely fast decompression scheme, also the smaller we make our binaries (in theory) the faster they should load, thus we get faster load times, with out having to resort to -Os (and therefore loss execution speed). At least that's the theory (as stated the in the thread). Also it seems like a fun little project for me, since I'll get to have a looksy at the portage code :) - the only problem seems to be adjusting the MD5 sums for unmerging and having a way to set enable/disable in global scope (I don't know how portage "works" at all so I don't know how hard this is to implement.) This is NOT about saving diskspace this is about reading less from the disk (remember harddrives are MUCH slower than ram, let alone the CPU). Saving diskspace seems to me like just a minor advantage here. Am I making sense or am I just totally wrong ? - Lovechild
Remember to read the UPX manpage first: ... How it works: Because Linux is a real operating system, the in-place in-memory decompression scheme used in the other executable formats doesn't work here. Instead we must use temporary decompression to disk. Interestingly - because of the good memory management of the Linux kernel - this often does not introduce a noticable delay, and in fact there will be no disk access at all if you have enough free memory as the entire process takes places within the filesystem buffers. ... - It is not advisable to compress programs which usually have many instances running (like `make') because the common segments of compressed programs won't be shared any longer between different processes. ...
Oh crap, back to the drawing board - I figured we could just make /tmp a ramdisk or keep it in ram all the time (that's what I gathered from reading the thread).. oh forget it, let's just close this sucker and get on with our lifes, I'm guessing the best way to decrease load times would be extensive use of the new prelinking features in glibc 2.3. - damned, the idea sounded so nice at first.
