Ubuntu QA:
BlogBrainstormPackage status
Log in
Ubuntu QA
The Ubuntu community has contributed 21986 ideas, 135057 comments, 2615221 votes
Idea sandbox Idea sandbox
Popular ideas Popular ideas
Ideas in development Ideas in development
Implemented ideas Implemented ideas
Idea #22869: Compress executables and libraries

Written by DrG the 8 Dec 09 at 09:50. Category: Others. Related project: Nothing/Others. Status: New
Rationale
This idea will be beneficial especially for live CDs , systems with small disk space and virtual machines.
Tags: (none)

-25
votes
up equal down
Solution #1: Compress executables and libraries.
Written by DrG the 8 Dec 09 at 09:50.
This idea will be beneficial especially for live CDs , systems with small disk space and virtual machines.

The basic idea behind executable compression -----------
There will be a switch in the header of the executable , system will look for this and decompress required parts of the file to memory . ( This will require kernel support . Another options are integrating a tiny decompresser inside the executable or using system's built in )
# ---------------------------


The live CD is already compressed , but with LZMA . LZMA is inferior to other algorithms like that of FreeArc (combines multiple algorithms including lzma ) ( http://freearc.org )
See - ( http://www.maximumcompression.com/data/summary_mf2.php )
FreeArc is more efficient than lzma , both in compression ratio and decompression time .
Compressing squashfs of Live CD with these algorithms is a better idea for live Cds.(Such Live CDs will carry more applications – see below)

But compressing executables and libraries ( with or without other data files – which only plays a minor role in the boot process ,most of them, like jpg has already got good compression already ) will help to reduce the size of installation , say for small netbooks or embedded .Furthermore Most of the Linux newbies are from windows and most of of them will try Ubuntu from virtual machines or from wubi .They will allow only a fraction of space for the virtual hard disk . If the installation is smaller they will be more comfortable .

Slow disk read time is the major factor which slows down a live CD compared to hard disc.
By better compression , the data to be read is much less . For most of the standard compression algorithms the time taken for decompression is very small ( compare to the existing lzma ). So the applications will be faster.

Let system or user determine the option.
As these algorithms are loss less they should be reversible to the original uncompressed version.
Most of the laptops and PCs have lavish disk space with fast read time . For them the compression may be of no value. In this situation
1.Allow system automatically decompress and install the uncompressed version as per the PC configurations.
2.Allow user to choose.

The amount of ram will not be an additional problem – The efficiency of the existing squashfs is lower.
#----------------------------------------------------------

Tail...
[[ compression of the executable 'gimp-2.6' size 4.1 MB (4341512 bytes) ( with aspire 4720z )
1.lzma (with switch -9) > 6 seconds > 1.2 MB (1229132 bytes)
2.arc (with switch -m9 ) > 5 seconds > 983.5 KB (1007090 bytes) ( 20 % reduction in size , 17 % in time compared to lzma ) . If we apply the same statitics to squashfs of live cd (may vary ), 140 MB reduction. That is 140 MB of new application can be added to Live CD if FreeArc is used instead of lzma . ]]

Propose your solution

Attachments
No attachments.


Duplicates


Comments
snostorm wrote on the 8 Dec 09 at 20:10
The Live CD is already compressed, and so are the packages from the software center. Besides reducing used hard disk space (Which isn't a problem for most modern hardware), I don't really see a benefit to this. Furthermore, it would break compatibility with other distros, which is something we do NOT want.

-1

Lachu wrote on the 8 Dec 09 at 20:58
Kernel have built in support for decompression.

I don't agree with rationale. Binaries don't require large amount of space. Decompression can provide problems if kernel vendors have decided to don't copy code of program onto swap, but load it from executable(i don't think he will decided to).

Only one purpose is making load binaries operation speeder for larger elf file. Somebody ever seen elf file with huge size?

Ssdg wrote on the 8 Dec 09 at 21:18
You forgot the problems your idea causes. it will need more RAM memory because it will force the kernel to have everything the program requires in computer's memory.

And programs will load slowly in comparison because of the decompression time (the bigger the programm, the slower the loading).

And I'm not sure executables have a good compression ration (scripts do, binaries... I'm quite sure you'll never get more than 5% of the program's size)

So, sorry, but the benefits are smalls compared to the loss of applying this.

DrG (Idea reviewer) wrote on the 9 Dec 09 at 04:47
@ snostorm
packages from the software centre are not sufficiently compressed . see http://brainstorm.ubuntu.com/idea/22854/ .
Compatibility with other distros - is ubuntu elf compatible with other disros ?

@ Lachu & @ Ssdg
Kernel have built in support for decompression , but we are talking about executables , to add another switch to executable , there should be a new support .
Executable 'gimp-2.6' size : 4.1 MB compressed with Freearc 983.5 KB (1007090 bytes) ie . More than 5% reduction .
It will need more RAM memory for the time for decompression. But will give back a faster system .
It will not force the kernel to have everything the program requires in computer's memory – because the live CD depend on the hard disk also . ( ! It can not handle the 600+ mb squashfs in a 512 Mb ram )

We are using loss less compression , so it will be completely reversible.
So the user or the system should be able to make the executables compressed or normal.


Post your comment