ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/liblzf/Changes
Revision: 1.54
Committed: Sun Mar 27 23:53:23 2011 UTC (13 years, 1 month ago) by root
Branch: MAIN
Changes since 1.53: +6 -0 lines
Log Message:
*** empty log message ***

File Contents

# Content
1
2 - switch to a multiplicative hash (developed with Steinar Gunderson),
3 which is faster on modern cpus and compresses a bit better. The old
4 hash function which uses only shifts is still available.
5 - allow user configurable hash table slots, which makes it possible
6 to use e.g. 16 bit offsets for a smaller hashtable (if your data is
7 always < 64kb).
8 - use _WIN32, not WIN32, when testing for windows (fails with bcc),
9 patch by Tamas Tevesz.
10
11 3.6 Mon Feb 7 17:37:31 CET 2011
12 - fixed hash calculation in C♯ version (Tiago Freitas Leal).
13 - unroll copy for small sizes, use memcpy for larger sizes,
14 greatly speeding up decompression in most cases.
15 - finally disable rep movsb - it's a big loss on modern intel cpus,
16 and only a small win on amd cpus.
17 - improve C++ compatibility of the code.
18 - slightly improve compressor speed.
19 - halved memory requirements for compressor on 64 bit architectures,
20 which can improve the speed quite a bit on older cpus.
21
22 3.5 Fri May 1 02:28:42 CEST 2009
23 - lzf_compress did sometimes write one octet past the given output
24 buffer (analyzed and nice testcase by Salvatore Sanfilippo).
25
26 3.4 Tue Sep 2 06:45:00 CEST 2008
27 - the fix from 3.3 introduced a compression bug, which is fixed in
28 this release (which explains the mysterious prerelease...). Thanks
29 once more to Clément Calmels.
30
31 3.3 Mon Aug 25 03:17:42 CEST 2008
32 - lzf_compress could access memory after the given input buffer
33 when outputting back references. reported with nice testcase
34 by Clément Calmels.
35
36 3.2 Fri May 9 18:52:23 CEST 2008
37 - include a workaround for failing POSIX and real-world compliance
38 on 64 bit windows (microsoft claims to support POSIX, but is far
39 from it). (bug found and analysed nicely by John Lilley).
40
41 3.1 Fri Nov 30 11:33:04 CET 2007
42 - IMPORTANT BUGFIX: a too long final literal run would corrupt data
43 in the encoder (this was introduced in 3.0 only, earlier versions
44 are safe).
45
46 3.0 Tue Nov 13 22:13:09 CET 2007
47 - switched to 2-clause bsd with "GPL v2 or any later version" option.
48 - speed up compression by ~10-15% in common cases
49 by some manual unrolling.
50 - import some compiler tricks from JSON::XS, for further speed-ups.
51 - tune hash functions depending on ULTRA_FAST or VERY_FAST settings.
52 - for typical binary data (e.g. /bin/bash, memory dumps,
53 canterbury corpus etc.), speed is now comparable to fastlz, but
54 with better compression ratio. with ULTRA_FAST, it's typically
55 3-15% faster than fastlz while still maintaining a similar ratio.
56 (amd64 and core 2 duo, ymmv). thanks a lot for the competition :)
57 - undo inline assembly in compressor, it is no longer helpful.
58 - no changes to the decompressor.
59 - use a HLOG of 16 by default now (formerly 15).
60
61 2.1 Fri Nov 2 13:34:42 CET 2007
62 - switched to a 2-clause bsd license with GPL exception.
63 - get rid of memcpy.
64 - tentatively use rep movsb on x86 and x86_64 (gcc only) for a
65 moderate speed improvement.
66 - applied patch by Kein-Hong Man to maske lzf.c compile under
67 the crippled mingw32 environment.
68
69 2.0 Fri Feb 16 23:11:18 CET 2007
70 - replaced lzf demo by industrial-strength lzf utility with behaviour
71 similar other compression utilities. Thanks for Stefan Traby for
72 rewriting it!
73 - fix state arg prototype.
74
75 1.7 Wed Sep 27 17:29:15 CEST 2006
76 - remove bogus "unlzf" patch.
77 note to self: never accept well-meant patches.
78 - make lzf more robust in presence of padding bytes or sudden eof.
79
80 1.6 Fri Jul 7 17:31:26 CEST 2006
81 - the lzf example utility will now uncompress if invoked
82 as "unlzf" (patch by Scott Feeney).
83 - add CHECK_INPUT option that adds more checks for input
84 data validity.
85 - help applications that do not pass in the correct length
86 (such as php) by returning either EINVAL or E2BIG.
87 - default HLOG size is now 15 (cpu caches have increased).
88 - documentation fixes.
89
90 1.51 Thu Apr 14 22:15:46 CEST 2005
91 - incorporated C♯ implementation of both the en- and decoder,
92 written by "Oren J. Maurice".
93 You can find it in the cs/ subdirectory.
94 - make FRST, NEXT IDX overridable if lzf_c.c is directly included
95 in the code.
96
97 1.5 Tue Mar 8 20:23:23 CET 2005
98 - incorporated improvements by Adam D. Moss,
99 which includes a new VERY_FAST mode which is
100 a bit slower than ULTRA_FAST but much better,
101 and enabled it as default.
102
103 1.401 Thu Mar 3 18:00:52 CET 2005
104 - use cstring in c++, not string.h.
105 - change of contact address.
106
107 1.4 Wed Dec 15 08:08:49 CET 2004
108 - very very slight tuning of the hashing function.
109
110 1.3 Thu Mar 25 15:41:17 CET 2004
111 - changed license of lzf core code to explicitly allow
112 relicensing under the GPLv2.
113 - added VPATH support as suggested by Björn Eriksson.
114
115 1.2 Mon Dec 29 13:47:28 CET 2003
116 - avoid spurious memory accesses after the to-be-compressed
117 memory region. originally reported by Michal Zalewski.
118 - flip LZF_STACK_ARG meaning (to be correct).
119
120 1.1 Tue Dec 23 05:48:32 CET 2003
121 - removed #warn directive, it's not worth the hassle.
122 - add LZF_STACK_ARG and AVOID_ERRNO configurations
123 for embedded systems.
124 - make it compile cleanly as c++.
125 - some small documentation and code fixes.
126
127 1.0 Sun Nov 17 12:37:37 CET 2002
128 - slightly better compression ratio, almost unmeasurably
129 slower.
130 - some documentation fixes.
131
132 0.4 Thu Jun 13 14:11:10 CEST 2002
133 - typoe fix.
134 - lzf demo program now properly decompresses small files.
135 - fix another 64 bit issue, found by Laurent Deniel.
136
137 0.3 Tue Jan 16 13:21:14 CET 2001
138 - fix silly beginners 32/64 bit mistake.
139
140 0.2 Thu Jan 4 05:56:42 CET 2001
141 - now totally independent of autoconfig, for
142 easy inclusion into other programs.
143 - much better fine-tuning, faster and better than 0.1.
144
145 0.1 2000
146 - initial release.