CompressionRatings.com

[Bulat Ziganshin]

Cyan, it's effictively large-dictionaries test. something like srep+... will handle it best

[Shelwien]

<sami> "If I didn't miss something, there isn't comment about how many cores 
does compressors used in each test cases. I think it is technical important."
<sami> this is not correct
<sami> the full tables show the cpu utilization
<sami> separately for compression and decompression
<sami> it's the percentage right beside the times
<sami> "Why random ? And not the usual TAR ?"
<sami> because the point was to force all comrpessors to treat this as just a file
<Shelwien> well, in theory somebody could parse the tar and still sort it :)
<sami> i will explain more once i get the site running again. 
there would be a lot to write about the decisions
<sami> some compressors parse tar files
<sami> maniscalco compressors and to my knowledge winrk
<Shelwien> :)
<sami> just to make it clear. i'm not using tar in that file, 
the files are copied into a single file in random order
<sami> i'd rather copy chunks of random size instead, 
but that would break the file formats

[Shelwien]

<Shelwien> Also new column layout is better I guess, 
<Shelwien> but imho many people (including me) would
<Shelwien> prefer the "output" swapped with "size" (even with ratings by "size")
<Sami> Who?

So, do you prefer Sami's version with "size" that includes decoder size
(which is the whole compressor in most cases), or plain output size
for the size column? http://compressionratings.com/sort.cgi?txt1.full+6n

[Cyan]

I guess the idea is probably to avoid decoders which would have parts of the object to decode in them ... This matters for ranking.

The size used for the ranking calculation needs to be mentioned. Whatever the name given to it.

So if the question is more about the column titled "size", this is more a matter of choice. I have none personally, and imho both Sami and yours proposals seem perfectly understandable.

[Shelwien]

Ok, let's make it more specific:

              "output" "size"
slug 1.24      309919 317263
etincelle b4   313590 352475

Here I added the size of 7z-compressed executables to the
size of compressed book1.
So, which column seems more fair to you?

Sure, for most of Sami's benchmarks it doesn't really matter,
but recently there're some with small files too.

Also, while it makes sense for some cases like HP, but in general,
having a built-in dictionary is still an advantage to
the compressor/archiver, even if the benchmark sizes become
the worst possible when decoder size is included.

[m^2]

Ok, let's make it more specific:

              "output" "size"
slug 1.24      309919 317263
etincelle b4   313590 352475

Here I added the size of 7z-compressed executables to the
size of compressed book1.
So, which column seems more fair to you?

Sure, for most of Sami's benchmarks it doesn't really matter,
but recently there're some with small files too.

Also, while it makes sense for some cases like HP, but in general,
having a built-in dictionary is still an advantage to
the compressor/archiver, even if the benchmark sizes become
the worst possible when decoder size is included.

IMO output is more fair.
In most cases where compression matters, decompressor size is negligible.
The only exceptions that I see are installers and compressors that have the benchmark file built-in. But Sami's benchmarks aren't popular enough yet.

[Bulat Ziganshin]

Sami removed App2 from main testset

[Fu Siyuan]

Sami removed App2 from main testset

yes, but he is still considering if testset like this is useful or how much weight should it be to measure applied compression performance.any others include nondevelopers have advices?