Notices

I've ported UPX to maemo. You can download the debian package at http://olya.com/maemo

Basically, UPX compresses executables to up to 1/5th of their size, freeing valuable space in device memory. There is almost no overhead to compression -- starting a 1Mb packed binary introduces only a 0.1 second delay.

I would encourage all developers (including Nokia) to start using UPX when releasing binaries.

I've compiled UPX for OS2008, but I am pretty sure it should also work on the older systems.

Enjoy.

Using executable compressors such as UPX is sometimes considered not a very good idea in linux. It saves some space on disk (flash memory), but makes RAM usage less efficient. For example, it prevents sharing of memory pages from code section between several instances of the same program running. It is a very bad choice for shared libraries because of this. Compressing the executables which are supposed to have only one instance running might be useful, but VM manager might also be somewhat hindered by it. Running normal executable, the system can free some less frequently used memory pages from the code section and fetch them back from the file image on disk any time later. This does not work when running UPX compressed executables, and the system needs to move less frequently used pages to swap when it is short on memory.

Did you estimate how much space you can save in reality? It would be nice to see a comparison between the size of .deb file with UPX compressed and original executable. Also how much saving provides UPX vs. jffs2 compression for the files stored on the internal flash?

By the way, regarding the efficient use of system memory. I wonder if all the shared libraries are assigned unique base virtual addresses in order not to have to be relocated on loading in all maemo OS versions. There is a tool called 'prelink' which can deal with all this stuff.

Serge,

Thanks for the feedback. These are good points. I haven't thought about the VM implications before.

Still, I feel that UPX would be appropriate for most applications. The difference between N810 and a typical linux computer is that the amount of device storage is extremely limited -- 100MB of free space vs. hundreds of gigabytes. By packing just a few binaries (especially those you don't use very frequently), you can save a few MB of valuable space. A typical 1MB binary can be compressed to about 250K.

About paging -- it appears that most IT applications are meant to be run as a single instance. Think about maemo mapper, quiver, most games, etc. It really wouldn't make sense to start them multiple times. I am also not sure how big a penalty it is that pages cannot be fetched from the file image on disk. It seems to me that internet tablets usually don't max out the available memory, so paging is not necessary. On the plus side, UPX applications can run faster, because no code needs to be fetched from disk after an application is started.

Also, please note that UPX doesn't handle shared libraries, only ELF executables.

I played around with UPX compression a bit on my Netbook Pro a couple years back. It greatly improved the startup time of programs with large executables like Minimo. UPX compression was really helpful on many Win CE devices that used shared ram for storage and program execution. I would be really curious to see if there is any performance benefit in using UPX compression on a selective basis on the NITs.

The question then, is how large is a given binary when compressed with jffs2 vs. the UPX compressed version of the same binary again "compressed" by jffs2?

As Serge already said, jffs2 filesystem is already compressed (there are several compression methods in kernel including gzip) so I'm afraid UPX only burns CPU cycles and RAM without significant savings in storage space. It can save space on SD/MMC card but that space is cheap and may not be worth the extra penalty.

I don't know direct way to see how well file is compressed in internal flash except using df to examine free space before and after creating a file. If you are concerned about space you can also tune jffs2 compression, I think in OS2008 firmware images Nokia decided to use method with worse compression ratio but better speed so you can go back and save few hundred KBs or maybe even magabyte or two by recompressing and reflashing rootfs.

Didn't realize the filesystem was already compressed. Never mind then.