On 09/23/2009 10:05 PM, Bill Nottingham wrote:
So... just set the xz compression level to 2, let it be that way for future
builds, and go about our business?
That's the best one-size-fits-all policy. We can do better because the
current xz compression algorithm is at least as bad as O(n*n). Restrict the
compression level to 2 for large .rpm, but use a higher level for smaller .rpm.
This will tend to avoid the largest time penalties yet still produce smaller
files for most .rpm.
Out of 4042 .rpm in my local cache (both i686 and x86_64):
number size
60 >= 10MB
138 >= 5MB
235 >= 3MB
344 >= 2MB
635 >= 1MB
720 >= 800KB
921 >= 500KB
1229 >= 300KB
1503 >= 200KB
2214 >= 100KB
Use something such as:
______size_____ level
< 200KB 7 (current)
200KB - 500KB 4
>= 500KB 2
On top of that, there could be a sliding scale based on release date.
From general availability release to next alpha, limit the level to 2
for all .rpm. From alpha to beta, limit the level to 4. From beta
to next general availability, use the size table. This tends to avoid
large time penalties for the cases most likely to be seen by end users,
yet still tends to give better compression for a full release.
[Of course, fix the *STUPID* endianness property.]
--
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
