balz v1.03 is here!

[encode]

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!

[Bulat Ziganshin]

try it with 512mb dict

[encode]

TORNADO already has 512m dict

[Bulat Ziganshin]

and what are results?

[Fallon]

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.

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.

[encode]

and what are results?

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

[Christian]

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.

[Fallon]

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

[encode]

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!

[encode]

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.

[Black_Fox1]

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.

[Fallon]

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.

[encode]

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

[Bulat Ziganshin]

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)