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.
