Need a Faster Compressor

Era Scarecrow via Digitalmars-d digitalmars-d at puremagic.com
Tue May 24 04:55:24 PDT 2016


On Monday, 23 May 2016 at 20:36:04 UTC, Walter Bright wrote:
> On 5/23/2016 9:00 AM, Stefan Koch wrote:
>> The 64k limit does not apply to the input string.
>
> The starting line of the compression function posted here tests 
> for it and aborts if larger.

  So Walter, big question: How big before the compressor kicks in? 
What's the minimum size of the input string the compressor should 
expect?

  Found something VERY interesting, I have 4 algorithms I'm 
benchmarking (the original and 3 edited compression routines). 
Most of them perform with similar speed (15-25% boost), but when 
I gave it a test by compressing raw D code of 20k big (for a big 
example), it suddenly showed an obvious winner between the 4 
(performing 5x faster than the original id_compress). This gain 
in speed wasn't obvious with a smaller string (1k or so), so 
assuming I'm getting good results this is very promising.

  id_compress: 1379ms (1379331μs), 22595	-> 8458 bytes
big_compress: 1186ms (1186608μs), 22595	-> 6784 bytes
   id_reduced:  626ms  (626750μs), 22595	-> 9618 bytes
min_compress:  262ms  (262340μs), 22595 -> 9266 bytes

  I assume speed is more important than a little loss in 
compression.


More information about the Digitalmars-d mailing list