upx

[Xiaopangzi]

I'm not sure if people are aware that the upx executable file compressor works fine for the ARM platform. It compresses executables and shared libraries (.so files). It could be run natively on the kindle or on an i386 linux, windows or other platform. It appears that upx on all platforms can compress binaries on all other supported platforms.

On modern desktop CPUs, decompression overhead is not an issue, but on the kindle there may be some small delay for large files. For example, the 8.5MB mplayer binary comresses to 4.0MB (upx --best) but adds a startup delay of 0.9 seconds. If one were to move the binary to the root partition where space is precious this seems a reasonable trade-off. Small files up to a few 100k do not show a noticeable startup delay. The delay is a little larger for compressed i386 binaries run on the kindle under qemu. For example, the 20MB kindlegen i386 linux binary compresses down to 6MB but adds more than 5 seconds delay.

Note that compressed binaries (especially shared libraries) do not always work so they should be tested. The compression is reversable (upx -d) in case of problems. It should be obvious that files are to be stripped before compression.

Comments or suggestions? Are there any executables on the root partition that would benefit from compression?

[yifanlu]

Originally Posted by Xiaopangzi

I'm not sure if people are aware that the upx executable file compressor works fine for the ARM platform. It compresses executables and shared libraries (.so files). It could be run natively on the kindle or on an i386 linux, windows or other platform. It appears that upx on all platforms can compress binaries on all other supported platforms.

On modern desktop CPUs, decompression overhead is not an issue, but on the kindle there may be some small delay for large files. For example, the 8.5MB mplayer binary comresses to 4.0MB (upx --best) but adds a startup delay of 0.9 seconds. If one were to move the binary to the root partition where space is precious this seems a reasonable trade-off. Small files up to a few 100k do not show a noticeable startup delay. The delay is a little larger for compressed i386 binaries run on the kindle under qemu. For example, the 20MB kindlegen i386 linux binary compresses down to 6MB but adds more than 5 seconds delay.

Note that compressed binaries (especially shared libraries) do not always work so they should be tested. The compression is reversable (upx -d) in case of problems. It should be obvious that files are to be stripped before compression.

Comments or suggestions? Are there any executables on the root partition that would benefit from compression?

I dont see how this is useful on the kindle. In speed vs size, kindle should be faster. At most, maybe 100MB can be saved, and we have a 2GB NAND.

[kranu]

I agree with Yifan Lu. The size difference would only be significant if the file was 1GB, but it the file was that big, the load time would also be significantly increased. I have ~1GB of space left on my Kindle, so I don't mind giving up a little space, so long as the load time is shorter.

Anyhow, thanks for sharing. This may become useful in the future, if we start to run out of space on the Kindle.

[Xiaopangzi]

I don't know about you but in order to get any work done on the kindle I need to replace half of the busybox tools with standalone executables providing missing functionality I rely on, I need a real bash, perl, python, basic text and image processing, mobigen, etc and I like them not clutter a fatfs-formatted rw-mounted data partition but be installed under /usr/local where they belong. That partition is only 650MB and 80% full, so I find the option to save space with upx compression very relevant and useful. Eventually, it will probably all be moved into a compressed image having to sit in /mnt/us and loop-mounted at /usr/local, but if that could be avoided it would be nice. I also do not think that the 3GB available in /mnt/us are excessive and expect them to fill up quickly.

[NIXin]

Why not create a loop device on the FAT partition and mount it under /usr/local ?
Problem solved.