isn't xz extremely slw with -9?
maybe it wasn't a bug, bit intentionally not used,
as that huge extra amount of time doesn't result in
that many bytes saved.
is the compression level configureable somehow?
Regards, Andreas
isn't xz extremely slw with -9?
maybe it wasn't a bug, bit intentionally not used,
as that huge extra amount of time doesn't result in
that many bytes saved.
Compared to the total time of make dist its IMHO
acceptable. But configurability won't hurt of course.
Pavel
Well, does somebody have numbers (memory, time, compression) as to what
is reasonable?
I didn't make any testing, but the report came from the observation
that result was +300kb on 9 mb. The compression was slow, but
decompression is not affected.
pavel
Pavel Sanda wrote:
the newly added dist-xz target produce worse compressed archives
than lzma-dist. The reason is that automake call lzma with
best compression while it won't use -9 level for xz.
Is this intention or bug?
It was deliberate.
For my use, xz -9 is far too slow for anything
Pavel Sanda wrote:
It was deliberate.
For my use, xz -9 is far too slow for anything except the
final make dist I run just prior to a release.
For a release, I run this, via one of the
alpha, beta or stable targets in gnulib's maint.mk:
$(MAKE) dist XZ_OPT=-9ev
Is it possible to
Pavel Sanda wrote:
Pavel Sanda wrote:
It was deliberate.
For my use, xz -9 is far too slow for anything except the
final make dist I run just prior to a release.
For a release, I run this, via one of the
alpha, beta or stable targets in gnulib's maint.mk:
$(MAKE) dist XZ_OPT=-9ev
Is
On 11 April 2010 23:37, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote:
Yes, compression is useful. However, the cost of pushing the algorithm
close to the limit does incur costs as well. For many packages, getting 99%
of the max in 1/2 the time is a worthy tradeoff. This is similar to
On Mon, 12 Apr 2010, Pavel Sanda wrote:
Pavel Sanda wrote:
It was deliberate.
For my use, xz -9 is far too slow for anything except the
final make dist I run just prior to a release.
For a release, I run this, via one of the
alpha, beta or stable targets in gnulib's maint.mk:
$(MAKE) dist
Hello,
* Jim Meyering wrote on Mon, Apr 12, 2010 at 11:44:01AM CEST:
Pavel Sanda wrote:
For my use, xz -9 is far too slow for anything except the
final make dist I run just prior to a release.
For a release, I run this, via one of the
alpha, beta or stable targets in gnulib's maint.mk:
Am Sonntag 11 April 2010 21:37:13 schrieb Andreas Jellinghaus:
isn't xz extremely slw with -9?
maybe it wasn't a bug, bit intentionally not used,
as that huge extra amount of time doesn't result in
that many bytes saved.
is the compression level configureable somehow?
I did two tests
Am Montag 12 April 2010 20:31:22 schrieb Ralf Wildenhues:
My idea would be to implement this for master, and revert the recent
xz -9 patch on branch-1.11. Comments, criticism?
if the environment variables can be used to set the compression,
that is perfect for me. why write your own code, when
* Andreas Jellinghaus wrote on Mon, Apr 12, 2010 at 09:41:44PM CEST:
Am Montag 12 April 2010 20:31:22 schrieb Ralf Wildenhues:
My idea would be to implement this for master, and revert the recent
xz -9 patch on branch-1.11. Comments, criticism?
if the environment variables can be used to
Hello Pavel,
* Pavel Sanda wrote on Wed, Apr 07, 2010 at 01:22:06PM CEST:
the newly added dist-xz target produce worse compressed archives
than lzma-dist. The reason is that automake call lzma with
best compression while it won't use -9 level for xz.
Is this intention or bug?
Bug, I guess.
Hello Andreas,
* Andreas Jellinghaus wrote on Sun, Apr 11, 2010 at 09:37:13PM CEST:
isn't xz extremely slw with -9?
maybe it wasn't a bug, bit intentionally not used,
as that huge extra amount of time doesn't result in
that many bytes saved.
Well, does somebody have numbers (memory,
Hello Pavel,
* Pavel Sanda wrote on Wed, Apr 07, 2010 at 01:22:06PM CEST:
the newly added dist-xz target produce worse compressed archives
than lzma-dist. The reason is that automake call lzma with
best compression while it won't use -9 level for xz.
Is this intention or bug?
Bug, I guess.
isn't xz extremely slw with -9?
maybe it wasn't a bug, bit intentionally not used,
as that huge extra amount of time doesn't result in
that many bytes saved.
is the compression level configureable somehow?
Regards, Andreas
Hello Andreas,
* Andreas Jellinghaus wrote on Sun, Apr 11, 2010 at 09:37:13PM CEST:
isn't xz extremely slw with -9?
maybe it wasn't a bug, bit intentionally not used,
as that huge extra amount of time doesn't result in
that many bytes saved.
Well, does somebody have numbers (memory,
isn't xz extremely slw with -9?
maybe it wasn't a bug, bit intentionally not used,
as that huge extra amount of time doesn't result in
that many bytes saved.
Compared to the total time of make dist its IMHO
acceptable. But configurability won't hurt of course.
Pavel
Well, does somebody have numbers (memory, time, compression) as to what
is reasonable?
I didn't make any testing, but the report came from the observation
that result was +300kb on 9 mb. The compression was slow, but
decompression is not affected.
pavel
On Sun, 11 Apr 2010, Pavel Sanda wrote:
isn't xz extremely slw with -9?
maybe it wasn't a bug, bit intentionally not used,
as that huge extra amount of time doesn't result in
that many bytes saved.
Compared to the total time of make dist its IMHO
acceptable. But configurability won't hurt
Are you assuming 'make dist' after 'make' or 'make dist' from scratch?
Other than the time spent compressing data, 'make dist' after 'make'
should be quite fast.
Yep, I mean the make dist from the scratch; i.e. what one usually
does when creating new release. The compression is used very
On Sun, 11 Apr 2010, Pavel Sanda wrote:
Are you assuming 'make dist' after 'make' or 'make dist' from scratch?
Other than the time spent compressing data, 'make dist' after 'make'
should be quite fast.
Yep, I mean the make dist from the scratch; i.e. what one usually
does when creating new
The same can be said about currently used -9 for lzma, no?
Yes. The argument is that it should be possible to optionally set the
compression level. In most cases, the compression default should be the
tool's compression default.
I have no problem with such solution.
Pavel
Hi,
the newly added dist-xz target produce worse compressed archives
than lzma-dist. The reason is that automake call lzma with
best compression while it won't use -9 level for xz.
Is this intention or bug?
Pavel
24 matches
Mail list logo
