Thread: balz v1.03 is here!

Added some match finder trick which drastically increases compression speed with large dictionaries; the text compression speed is crazily improved. In addition, found that 2 MB in most cases is much better than 1 MB, for example:

driver.tar (driver cache, 320,136,192 bytes)

BALZ v1.04, ex, 512k: 82,271,902 bytes
BALZ v1.04, ex, 1m: 76,534,871 bytes
BALZ v1.04, ex, 2m: 66,462,989 bytes
BALZ v1.04, ex, 4m: 63,979,864 bytes

Anyway, with new match finder the compression speed is OK even with 4 MB window.

Continue testing!

try it with 512mb dict

TORNADO already has 512m dict

and what are results?

Originally Posted by encode

Anyway, you may post your own thought about what BALZ do you really want to see – i.e. fast or not, favor compression or speed, etc.

High efficiency, maybe give up some in exchange for compression,
buth in truth, I will peek in and follow the ride to anywhere.

Originally Posted by encode

the coolest part of BALZ is its simplicity – I think its one of the simplest compressors ever made – BALZ v1.04 has ~7 KB source code

Attractive!
I take it that your attention for assymmetry has to do with practical use. Typical users probably wont give a rats ass (bulat: DGARA) about a 7 kb or 700 kb source, as long as it is wrapped up in one executable and runs fast enough.

Originally Posted by Bulat Ziganshin

and what are results?

TOR v0.4, -11: 56,116,831 bytes

Originally Posted by Fallon

Typical users probably wont give a rats ass (bulat: DGARA) about a 7 kb or 700 kb source

Still, a tiny source is always nice - is easy to maintain. Damn, even Slug has 8 kb source code. CCM and RZM both have around 20 kb.

Originally Posted by Christian

Still, a tiny source is always nice - is easy to maintain.

Well, I think new BALZ will have 4 MB window. Even granny UHARC has 4 MB dictionary by default. Having said that BALZ v1.04 is already a craziest thing - I think it will represent a big stride in my compression programs. The release is soon - just need do some tests&tunings and you'll see what's I'm talking about!

Originally Posted by Christian

Still, a tiny source is always nice - is easy to maintain. Damn, even Slug has 8 kb source code. CCM and RZM both have around 20 kb.

Some people that use my QUAD/LZPX source in their projects say that one of the best things about QUAD/LZPX is simplicity. Indeed ALL my sources are well structured - all variable/class/function names are carefully and logically chosen.

Originally Posted by encode

Maybe I should keep 4 MB, at least for "pht.psd" file.

Ooh Im honored
As far as BALZs heading is in question, try to learn things that allow you to make even better compressor in the future I wont mind if the compression speed was a little higher, though.

Originally Posted by encode

Some people that use my QUAD/LZPX source in their projects say that one of the best things about QUAD/LZPX is simplicity.

You are right. Thinking of the typical archiving user, for a moment I forgot about that mobile project that used your code, the implications of a good structure for use in such projects and in general for that matter.
Maybe I have been away too long. Anyway, I think of your work as original and excellent.

A 4 MB window will, as far as dictionary is concerned, let the program run on almost any old system. Thats probably a reason that RAR (and Ace) have sticked to 4mb as well.

+ Added 32 MB block size (instead of 16 MB)
+ Improved parsing

Originally Posted by Fallon

A 4 MB window will, as far as dictionary is concerned, let the program run on almost any old system.

yes, its exact reason why cabarc is limited to 2mb and rar/ace to 4mb (4mb is absolute minimum for win9x and 8mb is a practical one)