snappy 0.0.13 → 0.0.14
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/Gemfile +1 -1
- data/lib/snappy/version.rb +1 -1
- data/vendor/snappy/AUTHORS +1 -0
- data/vendor/snappy/COPYING +54 -0
- data/vendor/snappy/ChangeLog +1916 -0
- data/vendor/snappy/Makefile.am +23 -0
- data/vendor/snappy/NEWS +128 -0
- data/vendor/snappy/README +135 -0
- data/vendor/snappy/autogen.sh +7 -0
- data/vendor/snappy/configure.ac +133 -0
- data/vendor/snappy/format_description.txt +110 -0
- data/vendor/snappy/framing_format.txt +135 -0
- data/vendor/snappy/m4/gtest.m4 +74 -0
- data/vendor/snappy/snappy-c.cc +90 -0
- data/vendor/snappy/snappy-c.h +138 -0
- data/vendor/snappy/snappy-internal.h +150 -0
- data/vendor/snappy/snappy-sinksource.cc +71 -0
- data/vendor/snappy/snappy-sinksource.h +137 -0
- data/vendor/snappy/snappy-stubs-internal.cc +42 -0
- data/vendor/snappy/snappy-stubs-internal.h +491 -0
- data/vendor/snappy/snappy-stubs-public.h.in +98 -0
- data/vendor/snappy/snappy-test.cc +606 -0
- data/vendor/snappy/snappy-test.h +582 -0
- data/vendor/snappy/snappy.cc +1306 -0
- data/vendor/snappy/snappy.h +184 -0
- data/vendor/snappy/snappy_unittest.cc +1355 -0
- data/vendor/snappy/testdata/alice29.txt +3609 -0
- data/vendor/snappy/testdata/asyoulik.txt +4122 -0
- data/vendor/snappy/testdata/baddata1.snappy +0 -0
- data/vendor/snappy/testdata/baddata2.snappy +0 -0
- data/vendor/snappy/testdata/baddata3.snappy +0 -0
- data/vendor/snappy/testdata/fireworks.jpeg +0 -0
- data/vendor/snappy/testdata/geo.protodata +0 -0
- data/vendor/snappy/testdata/html +1 -0
- data/vendor/snappy/testdata/html_x_4 +1 -0
- data/vendor/snappy/testdata/kppkn.gtb +0 -0
- data/vendor/snappy/testdata/lcet10.txt +7519 -0
- data/vendor/snappy/testdata/paper-100k.pdf +600 -2
- data/vendor/snappy/testdata/plrabn12.txt +10699 -0
- data/vendor/snappy/testdata/urls.10K +10000 -0
- metadata +40 -2
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: a67639f9faf455c34ad523069275f720b75f4b67
|
4
|
+
data.tar.gz: b8b9c58aa5d98dc99f3fe9423f0eafaed5d7821a
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 8c34b97e31abd62d2145f04281107409156948638de98586baa3211ff369a4d45e9fa5d85d228657c2cdc00ba343be08ff5f7e7bf4e15df5bd69662ef8331eac
|
7
|
+
data.tar.gz: 2c773f0fd2e883b3c34c17edc65a53f5af352c34ad2234c639f7751c8ffb9b75ca7f10d375e51920ca494f828c68a73e2c58208077ec6c7bb7b6c31d3a40a83e
|
data/Gemfile
CHANGED
data/lib/snappy/version.rb
CHANGED
@@ -0,0 +1 @@
|
|
1
|
+
opensource@google.com
|
@@ -0,0 +1,54 @@
|
|
1
|
+
Copyright 2011, Google Inc.
|
2
|
+
All rights reserved.
|
3
|
+
|
4
|
+
Redistribution and use in source and binary forms, with or without
|
5
|
+
modification, are permitted provided that the following conditions are
|
6
|
+
met:
|
7
|
+
|
8
|
+
* Redistributions of source code must retain the above copyright
|
9
|
+
notice, this list of conditions and the following disclaimer.
|
10
|
+
* Redistributions in binary form must reproduce the above
|
11
|
+
copyright notice, this list of conditions and the following disclaimer
|
12
|
+
in the documentation and/or other materials provided with the
|
13
|
+
distribution.
|
14
|
+
* Neither the name of Google Inc. nor the names of its
|
15
|
+
contributors may be used to endorse or promote products derived from
|
16
|
+
this software without specific prior written permission.
|
17
|
+
|
18
|
+
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
19
|
+
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
20
|
+
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
21
|
+
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
22
|
+
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
23
|
+
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
24
|
+
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
25
|
+
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
26
|
+
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
27
|
+
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
28
|
+
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
29
|
+
|
30
|
+
===
|
31
|
+
|
32
|
+
Some of the benchmark data in util/zippy/testdata is licensed differently:
|
33
|
+
|
34
|
+
- fireworks.jpeg is Copyright 2013 Steinar H. Gunderson, and
|
35
|
+
is licensed under the Creative Commons Attribution 3.0 license
|
36
|
+
(CC-BY-3.0). See https://creativecommons.org/licenses/by/3.0/
|
37
|
+
for more information.
|
38
|
+
|
39
|
+
- kppkn.gtb is taken from the Gaviota chess tablebase set, and
|
40
|
+
is licensed under the MIT License. See
|
41
|
+
https://sites.google.com/site/gaviotachessengine/Home/endgame-tablebases-1
|
42
|
+
for more information.
|
43
|
+
|
44
|
+
- paper-100k.pdf is an excerpt (bytes 92160 to 194560) from the paper
|
45
|
+
“Combinatorial Modeling of Chromatin Features Quantitatively Predicts DNA
|
46
|
+
Replication Timing in _Drosophila_” by Federico Comoglio and Renato Paro,
|
47
|
+
which is licensed under the CC-BY license. See
|
48
|
+
http://www.ploscompbiol.org/static/license for more ifnormation.
|
49
|
+
|
50
|
+
- alice29.txt, asyoulik.txt, plrabn12.txt and lcet10.txt are from Project
|
51
|
+
Gutenberg. The first three have expired copyrights and are in the public
|
52
|
+
domain; the latter does not have expired copyright, but is still in the
|
53
|
+
public domain according to the license information
|
54
|
+
(http://www.gutenberg.org/ebooks/53).
|
@@ -0,0 +1,1916 @@
|
|
1
|
+
------------------------------------------------------------------------
|
2
|
+
r83 | snappy.mirrorbot@gmail.com | 2014-02-19 11:31:49 +0100 (Wed, 19 Feb 2014) | 9 lines
|
3
|
+
|
4
|
+
Fix public issue 82: Stop distributing benchmark data files that have
|
5
|
+
unclear or unsuitable licensing.
|
6
|
+
|
7
|
+
In general, we replace the files we can with liberally licensed data,
|
8
|
+
and remove all the others (in particular all the parts of the Canterbury
|
9
|
+
corpus that are not clearly in the public domain). The replacements
|
10
|
+
do not always have the exact same characteristics as the original ones,
|
11
|
+
but they are more than good enough to be useful for benchmarking.
|
12
|
+
|
13
|
+
------------------------------------------------------------------------
|
14
|
+
r82 | snappy.mirrorbot@gmail.com | 2013-10-25 15:31:27 +0200 (Fri, 25 Oct 2013) | 8 lines
|
15
|
+
|
16
|
+
Add support for padding in the Snappy framed format.
|
17
|
+
|
18
|
+
This is specifically motivated by DICOM's demands that embedded data
|
19
|
+
must be of an even number of bytes, but could in principle be used for
|
20
|
+
any sort of padding/alignment needed.
|
21
|
+
|
22
|
+
R=sanjay
|
23
|
+
|
24
|
+
------------------------------------------------------------------------
|
25
|
+
r81 | snappy.mirrorbot@gmail.com | 2013-10-15 17:21:31 +0200 (Tue, 15 Oct 2013) | 4 lines
|
26
|
+
|
27
|
+
Release Snappy 1.1.1.
|
28
|
+
|
29
|
+
R=jeff
|
30
|
+
|
31
|
+
------------------------------------------------------------------------
|
32
|
+
r80 | snappy.mirrorbot@gmail.com | 2013-08-13 14:55:00 +0200 (Tue, 13 Aug 2013) | 6 lines
|
33
|
+
|
34
|
+
Add autoconf tests for size_t and ssize_t. Sort-of resolves public issue 79;
|
35
|
+
it would solve the problem if MSVC typically used autoconf. However, it gives
|
36
|
+
a natural place (config.h) to put the typedef even for MSVC.
|
37
|
+
|
38
|
+
R=jsbell
|
39
|
+
|
40
|
+
------------------------------------------------------------------------
|
41
|
+
r79 | snappy.mirrorbot@gmail.com | 2013-07-29 13:06:44 +0200 (Mon, 29 Jul 2013) | 14 lines
|
42
|
+
|
43
|
+
When we compare the number of bytes produced with the offset for a
|
44
|
+
backreference, make the signedness of the bytes produced clear,
|
45
|
+
by sticking it into a size_t. This avoids a signed/unsigned compare
|
46
|
+
warning from MSVC (public issue 71), and also is slightly clearer.
|
47
|
+
|
48
|
+
Since the line is now so long the explanatory comment about the -1u
|
49
|
+
trick has to go somewhere else anyway, I used the opportunity to
|
50
|
+
explain it in slightly more detail.
|
51
|
+
|
52
|
+
This is a purely stylistic change; the emitted assembler from GCC
|
53
|
+
is identical.
|
54
|
+
|
55
|
+
R=jeff
|
56
|
+
|
57
|
+
------------------------------------------------------------------------
|
58
|
+
r78 | snappy.mirrorbot@gmail.com | 2013-06-30 21:24:03 +0200 (Sun, 30 Jun 2013) | 111 lines
|
59
|
+
|
60
|
+
In the fast path for decompressing literals, instead of checking
|
61
|
+
whether there's 16 bytes free and then checking right afterwards
|
62
|
+
(when having subtracted the literal size) that there are now
|
63
|
+
5 bytes free, just check once for 21 bytes. This skips a compare
|
64
|
+
and a branch; although it is easily predictable, it is still
|
65
|
+
a few cycles on a fast path that we would like to get rid of.
|
66
|
+
|
67
|
+
Benchmarking this yields very confusing results. On open-source
|
68
|
+
GCC 4.8.1 on Haswell, we get exactly the expected results; the
|
69
|
+
benchmarks where we hit the fast path for literals (in particular
|
70
|
+
the two HTML benchmarks and the protobuf benchmark) give very nice
|
71
|
+
speedups, and the others are not really affected.
|
72
|
+
|
73
|
+
However, benchmarks with Google's GCC branch on other hardware
|
74
|
+
is much less clear. It seems that we have a weak loss in some cases
|
75
|
+
(and the win for the “typical” win cases are not nearly as clear),
|
76
|
+
but that it depends on microarchitecture and plain luck in how we run
|
77
|
+
the benchmark. Looking at the generated assembler, it seems that
|
78
|
+
the removal of the if causes other large-scale changes in how the
|
79
|
+
function is laid out, which makes it likely that this is just bad luck.
|
80
|
+
|
81
|
+
Thus, we should keep this change, even though its exact current impact is
|
82
|
+
unclear; it's a sensible change per se, and dropping it on the basis of
|
83
|
+
microoptimization for a given compiler (or even branch of a compiler)
|
84
|
+
would seem like a bad strategy in the long run.
|
85
|
+
|
86
|
+
Microbenchmark results (all in 64-bit, opt mode):
|
87
|
+
|
88
|
+
Nehalem, Google GCC:
|
89
|
+
|
90
|
+
Benchmark Base (ns) New (ns) Improvement
|
91
|
+
------------------------------------------------------------------------------
|
92
|
+
BM_UFlat/0 76747 75591 1.3GB/s html +1.5%
|
93
|
+
BM_UFlat/1 765756 757040 886.3MB/s urls +1.2%
|
94
|
+
BM_UFlat/2 10867 10893 10.9GB/s jpg -0.2%
|
95
|
+
BM_UFlat/3 124 131 1.4GB/s jpg_200 -5.3%
|
96
|
+
BM_UFlat/4 31663 31596 2.8GB/s pdf +0.2%
|
97
|
+
BM_UFlat/5 314162 308176 1.2GB/s html4 +1.9%
|
98
|
+
BM_UFlat/6 29668 29746 790.6MB/s cp -0.3%
|
99
|
+
BM_UFlat/7 12958 13386 796.4MB/s c -3.2%
|
100
|
+
BM_UFlat/8 3596 3682 966.0MB/s lsp -2.3%
|
101
|
+
BM_UFlat/9 1019193 1033493 953.3MB/s xls -1.4%
|
102
|
+
BM_UFlat/10 239 247 775.3MB/s xls_200 -3.2%
|
103
|
+
BM_UFlat/11 236411 240271 606.9MB/s txt1 -1.6%
|
104
|
+
BM_UFlat/12 206639 209768 571.2MB/s txt2 -1.5%
|
105
|
+
BM_UFlat/13 627803 635722 641.4MB/s txt3 -1.2%
|
106
|
+
BM_UFlat/14 845932 857816 538.2MB/s txt4 -1.4%
|
107
|
+
BM_UFlat/15 402107 391670 1.2GB/s bin +2.7%
|
108
|
+
BM_UFlat/16 283 279 683.6MB/s bin_200 +1.4%
|
109
|
+
BM_UFlat/17 46070 46815 781.5MB/s sum -1.6%
|
110
|
+
BM_UFlat/18 5053 5163 782.0MB/s man -2.1%
|
111
|
+
BM_UFlat/19 79721 76581 1.4GB/s pb +4.1%
|
112
|
+
BM_UFlat/20 251158 252330 697.5MB/s gaviota -0.5%
|
113
|
+
Sum of all benchmarks 4966150 4980396 -0.3%
|
114
|
+
|
115
|
+
|
116
|
+
Sandy Bridge, Google GCC:
|
117
|
+
|
118
|
+
Benchmark Base (ns) New (ns) Improvement
|
119
|
+
------------------------------------------------------------------------------
|
120
|
+
BM_UFlat/0 42850 42182 2.3GB/s html +1.6%
|
121
|
+
BM_UFlat/1 525660 515816 1.3GB/s urls +1.9%
|
122
|
+
BM_UFlat/2 7173 7283 16.3GB/s jpg -1.5%
|
123
|
+
BM_UFlat/3 92 91 2.1GB/s jpg_200 +1.1%
|
124
|
+
BM_UFlat/4 15147 14872 5.9GB/s pdf +1.8%
|
125
|
+
BM_UFlat/5 199936 192116 2.0GB/s html4 +4.1%
|
126
|
+
BM_UFlat/6 12796 12443 1.8GB/s cp +2.8%
|
127
|
+
BM_UFlat/7 6588 6400 1.6GB/s c +2.9%
|
128
|
+
BM_UFlat/8 2010 1951 1.8GB/s lsp +3.0%
|
129
|
+
BM_UFlat/9 761124 763049 1.3GB/s xls -0.3%
|
130
|
+
BM_UFlat/10 186 189 1016.1MB/s xls_200 -1.6%
|
131
|
+
BM_UFlat/11 159354 158460 918.6MB/s txt1 +0.6%
|
132
|
+
BM_UFlat/12 139732 139950 856.1MB/s txt2 -0.2%
|
133
|
+
BM_UFlat/13 429917 425027 961.7MB/s txt3 +1.2%
|
134
|
+
BM_UFlat/14 585255 587324 785.8MB/s txt4 -0.4%
|
135
|
+
BM_UFlat/15 276186 266173 1.8GB/s bin +3.8%
|
136
|
+
BM_UFlat/16 205 207 925.5MB/s bin_200 -1.0%
|
137
|
+
BM_UFlat/17 24925 24935 1.4GB/s sum -0.0%
|
138
|
+
BM_UFlat/18 2632 2576 1.5GB/s man +2.2%
|
139
|
+
BM_UFlat/19 40546 39108 2.8GB/s pb +3.7%
|
140
|
+
BM_UFlat/20 175803 168209 1048.9MB/s gaviota +4.5%
|
141
|
+
Sum of all benchmarks 3408117 3368361 +1.2%
|
142
|
+
|
143
|
+
|
144
|
+
Haswell, upstream GCC 4.8.1:
|
145
|
+
|
146
|
+
Benchmark Base (ns) New (ns) Improvement
|
147
|
+
------------------------------------------------------------------------------
|
148
|
+
BM_UFlat/0 46308 40641 2.3GB/s html +13.9%
|
149
|
+
BM_UFlat/1 513385 514706 1.3GB/s urls -0.3%
|
150
|
+
BM_UFlat/2 6197 6151 19.2GB/s jpg +0.7%
|
151
|
+
BM_UFlat/3 61 61 3.0GB/s jpg_200 +0.0%
|
152
|
+
BM_UFlat/4 13551 13429 6.5GB/s pdf +0.9%
|
153
|
+
BM_UFlat/5 198317 190243 2.0GB/s html4 +4.2%
|
154
|
+
BM_UFlat/6 14768 12560 1.8GB/s cp +17.6%
|
155
|
+
BM_UFlat/7 6453 6447 1.6GB/s c +0.1%
|
156
|
+
BM_UFlat/8 1991 1980 1.8GB/s lsp +0.6%
|
157
|
+
BM_UFlat/9 766947 770424 1.2GB/s xls -0.5%
|
158
|
+
BM_UFlat/10 170 169 1.1GB/s xls_200 +0.6%
|
159
|
+
BM_UFlat/11 164350 163554 888.7MB/s txt1 +0.5%
|
160
|
+
BM_UFlat/12 145444 143830 832.1MB/s txt2 +1.1%
|
161
|
+
BM_UFlat/13 437849 438413 929.2MB/s txt3 -0.1%
|
162
|
+
BM_UFlat/14 603587 605309 759.8MB/s txt4 -0.3%
|
163
|
+
BM_UFlat/15 249799 248067 1.9GB/s bin +0.7%
|
164
|
+
BM_UFlat/16 191 188 1011.4MB/s bin_200 +1.6%
|
165
|
+
BM_UFlat/17 26064 24778 1.4GB/s sum +5.2%
|
166
|
+
BM_UFlat/18 2620 2601 1.5GB/s man +0.7%
|
167
|
+
BM_UFlat/19 44551 37373 3.0GB/s pb +19.2%
|
168
|
+
BM_UFlat/20 165408 164584 1.0GB/s gaviota +0.5%
|
169
|
+
Sum of all benchmarks 3408011 3385508 +0.7%
|
170
|
+
|
171
|
+
------------------------------------------------------------------------
|
172
|
+
r77 | snappy.mirrorbot@gmail.com | 2013-06-14 23:42:26 +0200 (Fri, 14 Jun 2013) | 92 lines
|
173
|
+
|
174
|
+
Make the two IncrementalCopy* functions take in an ssize_t instead of a len,
|
175
|
+
in order to avoid having to do 32-to-64-bit signed conversions on a hot path
|
176
|
+
during decompression. (Also fixes some MSVC warnings, mentioned in public
|
177
|
+
issue 75, but more of those remain.) They cannot be size_t because we expect
|
178
|
+
them to go negative and test for that.
|
179
|
+
|
180
|
+
This saves a few movzwl instructions, yielding ~2% speedup in decompression.
|
181
|
+
|
182
|
+
|
183
|
+
Sandy Bridge:
|
184
|
+
|
185
|
+
Benchmark Base (ns) New (ns) Improvement
|
186
|
+
-------------------------------------------------------------------------------------------------
|
187
|
+
BM_UFlat/0 48009 41283 2.3GB/s html +16.3%
|
188
|
+
BM_UFlat/1 531274 513419 1.3GB/s urls +3.5%
|
189
|
+
BM_UFlat/2 7378 7062 16.8GB/s jpg +4.5%
|
190
|
+
BM_UFlat/3 92 92 2.0GB/s jpg_200 +0.0%
|
191
|
+
BM_UFlat/4 15057 14974 5.9GB/s pdf +0.6%
|
192
|
+
BM_UFlat/5 204323 193140 2.0GB/s html4 +5.8%
|
193
|
+
BM_UFlat/6 13282 12611 1.8GB/s cp +5.3%
|
194
|
+
BM_UFlat/7 6511 6504 1.6GB/s c +0.1%
|
195
|
+
BM_UFlat/8 2014 2030 1.7GB/s lsp -0.8%
|
196
|
+
BM_UFlat/9 775909 768336 1.3GB/s xls +1.0%
|
197
|
+
BM_UFlat/10 182 184 1043.2MB/s xls_200 -1.1%
|
198
|
+
BM_UFlat/11 167352 161630 901.2MB/s txt1 +3.5%
|
199
|
+
BM_UFlat/12 147393 142246 842.8MB/s txt2 +3.6%
|
200
|
+
BM_UFlat/13 449960 432853 944.4MB/s txt3 +4.0%
|
201
|
+
BM_UFlat/14 620497 594845 775.9MB/s txt4 +4.3%
|
202
|
+
BM_UFlat/15 265610 267356 1.8GB/s bin -0.7%
|
203
|
+
BM_UFlat/16 206 205 932.7MB/s bin_200 +0.5%
|
204
|
+
BM_UFlat/17 25561 24730 1.4GB/s sum +3.4%
|
205
|
+
BM_UFlat/18 2620 2644 1.5GB/s man -0.9%
|
206
|
+
BM_UFlat/19 45766 38589 2.9GB/s pb +18.6%
|
207
|
+
BM_UFlat/20 171107 169832 1039.5MB/s gaviota +0.8%
|
208
|
+
Sum of all benchmarks 3500103 3394565 +3.1%
|
209
|
+
|
210
|
+
|
211
|
+
Westmere:
|
212
|
+
|
213
|
+
Benchmark Base (ns) New (ns) Improvement
|
214
|
+
-------------------------------------------------------------------------------------------------
|
215
|
+
BM_UFlat/0 72624 71526 1.3GB/s html +1.5%
|
216
|
+
BM_UFlat/1 735821 722917 930.8MB/s urls +1.8%
|
217
|
+
BM_UFlat/2 10450 10172 11.7GB/s jpg +2.7%
|
218
|
+
BM_UFlat/3 117 117 1.6GB/s jpg_200 +0.0%
|
219
|
+
BM_UFlat/4 29817 29648 3.0GB/s pdf +0.6%
|
220
|
+
BM_UFlat/5 297126 293073 1.3GB/s html4 +1.4%
|
221
|
+
BM_UFlat/6 28252 27994 842.0MB/s cp +0.9%
|
222
|
+
BM_UFlat/7 12672 12391 862.1MB/s c +2.3%
|
223
|
+
BM_UFlat/8 3507 3425 1040.9MB/s lsp +2.4%
|
224
|
+
BM_UFlat/9 1004268 969395 1018.0MB/s xls +3.6%
|
225
|
+
BM_UFlat/10 233 227 844.8MB/s xls_200 +2.6%
|
226
|
+
BM_UFlat/11 230054 224981 647.8MB/s txt1 +2.3%
|
227
|
+
BM_UFlat/12 201229 196447 610.5MB/s txt2 +2.4%
|
228
|
+
BM_UFlat/13 609547 596761 685.3MB/s txt3 +2.1%
|
229
|
+
BM_UFlat/14 824362 804821 573.8MB/s txt4 +2.4%
|
230
|
+
BM_UFlat/15 371095 374899 1.3GB/s bin -1.0%
|
231
|
+
BM_UFlat/16 267 267 717.8MB/s bin_200 +0.0%
|
232
|
+
BM_UFlat/17 44623 43828 835.9MB/s sum +1.8%
|
233
|
+
BM_UFlat/18 5077 4815 841.0MB/s man +5.4%
|
234
|
+
BM_UFlat/19 74964 73210 1.5GB/s pb +2.4%
|
235
|
+
BM_UFlat/20 237987 236745 746.0MB/s gaviota +0.5%
|
236
|
+
Sum of all benchmarks 4794092 4697659 +2.1%
|
237
|
+
|
238
|
+
|
239
|
+
Istanbul:
|
240
|
+
|
241
|
+
Benchmark Base (ns) New (ns) Improvement
|
242
|
+
-------------------------------------------------------------------------------------------------
|
243
|
+
BM_UFlat/0 98614 96376 1020.4MB/s html +2.3%
|
244
|
+
BM_UFlat/1 963740 953241 707.2MB/s urls +1.1%
|
245
|
+
BM_UFlat/2 25042 24769 4.8GB/s jpg +1.1%
|
246
|
+
BM_UFlat/3 180 180 1065.6MB/s jpg_200 +0.0%
|
247
|
+
BM_UFlat/4 45942 45403 1.9GB/s pdf +1.2%
|
248
|
+
BM_UFlat/5 400135 390226 1008.2MB/s html4 +2.5%
|
249
|
+
BM_UFlat/6 37768 37392 631.9MB/s cp +1.0%
|
250
|
+
BM_UFlat/7 18585 18200 588.2MB/s c +2.1%
|
251
|
+
BM_UFlat/8 5751 5690 627.7MB/s lsp +1.1%
|
252
|
+
BM_UFlat/9 1543154 1542209 641.4MB/s xls +0.1%
|
253
|
+
BM_UFlat/10 381 388 494.6MB/s xls_200 -1.8%
|
254
|
+
BM_UFlat/11 339715 331973 440.1MB/s txt1 +2.3%
|
255
|
+
BM_UFlat/12 294807 289418 415.4MB/s txt2 +1.9%
|
256
|
+
BM_UFlat/13 906160 884094 463.3MB/s txt3 +2.5%
|
257
|
+
BM_UFlat/14 1224221 1198435 386.1MB/s txt4 +2.2%
|
258
|
+
BM_UFlat/15 516277 502923 979.5MB/s bin +2.7%
|
259
|
+
BM_UFlat/16 405 402 477.2MB/s bin_200 +0.7%
|
260
|
+
BM_UFlat/17 61640 60621 605.6MB/s sum +1.7%
|
261
|
+
BM_UFlat/18 7326 7383 549.5MB/s man -0.8%
|
262
|
+
BM_UFlat/19 94720 92653 1.2GB/s pb +2.2%
|
263
|
+
BM_UFlat/20 360435 346687 510.6MB/s gaviota +4.0%
|
264
|
+
Sum of all benchmarks 6944998 6828663 +1.7%
|
265
|
+
|
266
|
+
------------------------------------------------------------------------
|
267
|
+
r76 | snappy.mirrorbot@gmail.com | 2013-06-13 18:19:52 +0200 (Thu, 13 Jun 2013) | 9 lines
|
268
|
+
|
269
|
+
Add support for uncompressing to iovecs (scatter I/O).
|
270
|
+
Windows does not have struct iovec defined anywhere,
|
271
|
+
so we define our own version that's equal to what UNIX
|
272
|
+
typically has.
|
273
|
+
|
274
|
+
The bulk of this patch was contributed by Mohit Aron.
|
275
|
+
|
276
|
+
R=jeff
|
277
|
+
|
278
|
+
------------------------------------------------------------------------
|
279
|
+
r75 | snappy.mirrorbot@gmail.com | 2013-06-12 21:51:15 +0200 (Wed, 12 Jun 2013) | 4 lines
|
280
|
+
|
281
|
+
Some code reorganization needed for an internal change.
|
282
|
+
|
283
|
+
R=fikes
|
284
|
+
|
285
|
+
------------------------------------------------------------------------
|
286
|
+
r74 | snappy.mirrorbot@gmail.com | 2013-04-09 17:33:30 +0200 (Tue, 09 Apr 2013) | 4 lines
|
287
|
+
|
288
|
+
Supports truncated test data in zippy benchmark.
|
289
|
+
|
290
|
+
R=sesse
|
291
|
+
|
292
|
+
------------------------------------------------------------------------
|
293
|
+
r73 | snappy.mirrorbot@gmail.com | 2013-02-05 15:36:15 +0100 (Tue, 05 Feb 2013) | 4 lines
|
294
|
+
|
295
|
+
Release Snappy 1.1.0.
|
296
|
+
|
297
|
+
R=sanjay
|
298
|
+
|
299
|
+
------------------------------------------------------------------------
|
300
|
+
r72 | snappy.mirrorbot@gmail.com | 2013-02-05 15:30:05 +0100 (Tue, 05 Feb 2013) | 9 lines
|
301
|
+
|
302
|
+
Make ./snappy_unittest pass without "srcdir" being defined.
|
303
|
+
|
304
|
+
Previously, snappy_unittests would read from an absolute path /testdata/..;
|
305
|
+
convert it to use a relative path instead.
|
306
|
+
|
307
|
+
Patch from Marc-Antonie Ruel.
|
308
|
+
|
309
|
+
R=maruel
|
310
|
+
|
311
|
+
------------------------------------------------------------------------
|
312
|
+
r71 | snappy.mirrorbot@gmail.com | 2013-01-18 13:16:36 +0100 (Fri, 18 Jan 2013) | 287 lines
|
313
|
+
|
314
|
+
Increase the Zippy block size from 32 kB to 64 kB, winning ~3% density
|
315
|
+
while being effectively performance neutral.
|
316
|
+
|
317
|
+
The longer story about density is that we win 3-6% density on the benchmarks
|
318
|
+
where this has any effect at all; many of the benchmarks (cp, c, lsp, man)
|
319
|
+
are smaller than 32 kB and thus will have no effect. Binary data also seems
|
320
|
+
to win little or nothing; of course, the already-compressed data wins nothing.
|
321
|
+
The protobuf benchmark wins as much as ~18% depending on architecture,
|
322
|
+
but I wouldn't be too sure that this is representative of protobuf data in
|
323
|
+
general.
|
324
|
+
|
325
|
+
As of performance, we lose a tiny amount since we get more tags (e.g., a long
|
326
|
+
literal might be broken up into literal-copy-literal), but we win it back with
|
327
|
+
less clearing of the hash table, and more opportunities to skip incompressible
|
328
|
+
data (e.g. in the jpg benchmark). Decompression seems to get ever so slightly
|
329
|
+
slower, again due to more tags. The total net change is about as close to zero
|
330
|
+
as we can get, so the end effect seems to be simply more density and no
|
331
|
+
real performance change.
|
332
|
+
|
333
|
+
The comment about not changing kBlockSize, scary as it is, is not really
|
334
|
+
relevant, since we're never going to have a block-level decompressor without
|
335
|
+
explicitly marked blocks. Replace it with something more appropriate.
|
336
|
+
|
337
|
+
This affects the framing format, but it's okay to change it since it basically
|
338
|
+
has no users yet.
|
339
|
+
|
340
|
+
|
341
|
+
Density (note that cp, c, lsp and man are all smaller than 32 kB):
|
342
|
+
|
343
|
+
Benchmark Description Base (%) New (%) Improvement
|
344
|
+
--------------------------------------------------------------
|
345
|
+
ZFlat/0 html 22.57 22.31 +5.6%
|
346
|
+
ZFlat/1 urls 50.89 47.77 +6.5%
|
347
|
+
ZFlat/2 jpg 99.88 99.87 +0.0%
|
348
|
+
ZFlat/3 pdf 82.13 82.07 +0.1%
|
349
|
+
ZFlat/4 html4 23.55 22.51 +4.6%
|
350
|
+
ZFlat/5 cp 48.12 48.12 +0.0%
|
351
|
+
ZFlat/6 c 42.40 42.40 +0.0%
|
352
|
+
ZFlat/7 lsp 48.37 48.37 +0.0%
|
353
|
+
ZFlat/8 xls 41.34 41.23 +0.3%
|
354
|
+
ZFlat/9 txt1 59.81 57.87 +3.4%
|
355
|
+
ZFlat/10 txt2 64.07 61.93 +3.5%
|
356
|
+
ZFlat/11 txt3 57.11 54.92 +4.0%
|
357
|
+
ZFlat/12 txt4 68.35 66.22 +3.2%
|
358
|
+
ZFlat/13 bin 18.21 18.11 +0.6%
|
359
|
+
ZFlat/14 sum 51.88 48.96 +6.0%
|
360
|
+
ZFlat/15 man 59.36 59.36 +0.0%
|
361
|
+
ZFlat/16 pb 23.15 19.64 +17.9%
|
362
|
+
ZFlat/17 gaviota 38.27 37.72 +1.5%
|
363
|
+
Geometric mean 45.51 44.15 +3.1%
|
364
|
+
|
365
|
+
|
366
|
+
Microbenchmarks (64-bit, opt):
|
367
|
+
|
368
|
+
Westmere 2.8 GHz:
|
369
|
+
|
370
|
+
Benchmark Base (ns) New (ns) Improvement
|
371
|
+
-------------------------------------------------------------------------------------------------
|
372
|
+
BM_UFlat/0 75342 75027 1.3GB/s html +0.4%
|
373
|
+
BM_UFlat/1 723767 744269 899.6MB/s urls -2.8%
|
374
|
+
BM_UFlat/2 10072 10072 11.7GB/s jpg +0.0%
|
375
|
+
BM_UFlat/3 30747 30388 2.9GB/s pdf +1.2%
|
376
|
+
BM_UFlat/4 307353 306063 1.2GB/s html4 +0.4%
|
377
|
+
BM_UFlat/5 28593 28743 816.3MB/s cp -0.5%
|
378
|
+
BM_UFlat/6 12958 12998 818.1MB/s c -0.3%
|
379
|
+
BM_UFlat/7 3700 3792 935.8MB/s lsp -2.4%
|
380
|
+
BM_UFlat/8 999685 999905 982.1MB/s xls -0.0%
|
381
|
+
BM_UFlat/9 232954 230079 630.4MB/s txt1 +1.2%
|
382
|
+
BM_UFlat/10 200785 201468 592.6MB/s txt2 -0.3%
|
383
|
+
BM_UFlat/11 617267 610968 666.1MB/s txt3 +1.0%
|
384
|
+
BM_UFlat/12 821595 822475 558.7MB/s txt4 -0.1%
|
385
|
+
BM_UFlat/13 377097 377632 1.3GB/s bin -0.1%
|
386
|
+
BM_UFlat/14 45476 45260 805.8MB/s sum +0.5%
|
387
|
+
BM_UFlat/15 4985 5003 805.7MB/s man -0.4%
|
388
|
+
BM_UFlat/16 80813 77494 1.4GB/s pb +4.3%
|
389
|
+
BM_UFlat/17 251792 241553 727.7MB/s gaviota +4.2%
|
390
|
+
BM_UValidate/0 40343 40354 2.4GB/s html -0.0%
|
391
|
+
BM_UValidate/1 426890 451574 1.4GB/s urls -5.5%
|
392
|
+
BM_UValidate/2 187 179 661.9GB/s jpg +4.5%
|
393
|
+
BM_UValidate/3 13783 13827 6.4GB/s pdf -0.3%
|
394
|
+
BM_UValidate/4 162393 163335 2.3GB/s html4 -0.6%
|
395
|
+
BM_UDataBuffer/0 93756 93302 1046.7MB/s html +0.5%
|
396
|
+
BM_UDataBuffer/1 886714 916292 730.7MB/s urls -3.2%
|
397
|
+
BM_UDataBuffer/2 15861 16401 7.2GB/s jpg -3.3%
|
398
|
+
BM_UDataBuffer/3 38934 39224 2.2GB/s pdf -0.7%
|
399
|
+
BM_UDataBuffer/4 381008 379428 1029.5MB/s html4 +0.4%
|
400
|
+
BM_UCord/0 92528 91098 1072.0MB/s html +1.6%
|
401
|
+
BM_UCord/1 858421 885287 756.3MB/s urls -3.0%
|
402
|
+
BM_UCord/2 13140 13464 8.8GB/s jpg -2.4%
|
403
|
+
BM_UCord/3 39012 37773 2.3GB/s pdf +3.3%
|
404
|
+
BM_UCord/4 376869 371267 1052.1MB/s html4 +1.5%
|
405
|
+
BM_UCordString/0 75810 75303 1.3GB/s html +0.7%
|
406
|
+
BM_UCordString/1 735290 753841 888.2MB/s urls -2.5%
|
407
|
+
BM_UCordString/2 11945 13113 9.0GB/s jpg -8.9%
|
408
|
+
BM_UCordString/3 33901 32562 2.7GB/s pdf +4.1%
|
409
|
+
BM_UCordString/4 310985 309390 1.2GB/s html4 +0.5%
|
410
|
+
BM_UCordValidate/0 40952 40450 2.4GB/s html +1.2%
|
411
|
+
BM_UCordValidate/1 433842 456531 1.4GB/s urls -5.0%
|
412
|
+
BM_UCordValidate/2 1179 1173 100.8GB/s jpg +0.5%
|
413
|
+
BM_UCordValidate/3 14481 14392 6.1GB/s pdf +0.6%
|
414
|
+
BM_UCordValidate/4 164364 164151 2.3GB/s html4 +0.1%
|
415
|
+
BM_ZFlat/0 160610 156601 623.6MB/s html (22.31 %) +2.6%
|
416
|
+
BM_ZFlat/1 1995238 1993582 335.9MB/s urls (47.77 %) +0.1%
|
417
|
+
BM_ZFlat/2 30133 24983 4.7GB/s jpg (99.87 %) +20.6%
|
418
|
+
BM_ZFlat/3 74453 73128 1.2GB/s pdf (82.07 %) +1.8%
|
419
|
+
BM_ZFlat/4 647674 633729 616.4MB/s html4 (22.51 %) +2.2%
|
420
|
+
BM_ZFlat/5 76259 76090 308.4MB/s cp (48.12 %) +0.2%
|
421
|
+
BM_ZFlat/6 31106 31084 342.1MB/s c (42.40 %) +0.1%
|
422
|
+
BM_ZFlat/7 10507 10443 339.8MB/s lsp (48.37 %) +0.6%
|
423
|
+
BM_ZFlat/8 1811047 1793325 547.6MB/s xls (41.23 %) +1.0%
|
424
|
+
BM_ZFlat/9 597903 581793 249.3MB/s txt1 (57.87 %) +2.8%
|
425
|
+
BM_ZFlat/10 525320 514522 232.0MB/s txt2 (61.93 %) +2.1%
|
426
|
+
BM_ZFlat/11 1596591 1551636 262.3MB/s txt3 (54.92 %) +2.9%
|
427
|
+
BM_ZFlat/12 2134523 2094033 219.5MB/s txt4 (66.22 %) +1.9%
|
428
|
+
BM_ZFlat/13 593024 587869 832.6MB/s bin (18.11 %) +0.9%
|
429
|
+
BM_ZFlat/14 114746 110666 329.5MB/s sum (48.96 %) +3.7%
|
430
|
+
BM_ZFlat/15 14376 14485 278.3MB/s man (59.36 %) -0.8%
|
431
|
+
BM_ZFlat/16 167908 150070 753.6MB/s pb (19.64 %) +11.9%
|
432
|
+
BM_ZFlat/17 460228 442253 397.5MB/s gaviota (37.72 %) +4.1%
|
433
|
+
BM_ZCord/0 164896 160241 609.4MB/s html +2.9%
|
434
|
+
BM_ZCord/1 2070239 2043492 327.7MB/s urls +1.3%
|
435
|
+
BM_ZCord/2 54402 47002 2.5GB/s jpg +15.7%
|
436
|
+
BM_ZCord/3 85871 83832 1073.1MB/s pdf +2.4%
|
437
|
+
BM_ZCord/4 664078 648825 602.0MB/s html4 +2.4%
|
438
|
+
BM_ZDataBuffer/0 174874 172549 566.0MB/s html +1.3%
|
439
|
+
BM_ZDataBuffer/1 2134410 2139173 313.0MB/s urls -0.2%
|
440
|
+
BM_ZDataBuffer/2 71911 69551 1.7GB/s jpg +3.4%
|
441
|
+
BM_ZDataBuffer/3 98236 99727 902.1MB/s pdf -1.5%
|
442
|
+
BM_ZDataBuffer/4 710776 699104 558.8MB/s html4 +1.7%
|
443
|
+
Sum of all benchmarks 27358908 27200688 +0.6%
|
444
|
+
|
445
|
+
|
446
|
+
Sandy Bridge 2.6 GHz:
|
447
|
+
|
448
|
+
Benchmark Base (ns) New (ns) Improvement
|
449
|
+
-------------------------------------------------------------------------------------------------
|
450
|
+
BM_UFlat/0 49356 49018 1.9GB/s html +0.7%
|
451
|
+
BM_UFlat/1 516764 531955 1.2GB/s urls -2.9%
|
452
|
+
BM_UFlat/2 6982 7304 16.2GB/s jpg -4.4%
|
453
|
+
BM_UFlat/3 15285 15598 5.6GB/s pdf -2.0%
|
454
|
+
BM_UFlat/4 206557 206669 1.8GB/s html4 -0.1%
|
455
|
+
BM_UFlat/5 13681 13567 1.7GB/s cp +0.8%
|
456
|
+
BM_UFlat/6 6571 6592 1.6GB/s c -0.3%
|
457
|
+
BM_UFlat/7 2008 1994 1.7GB/s lsp +0.7%
|
458
|
+
BM_UFlat/8 775700 773286 1.2GB/s xls +0.3%
|
459
|
+
BM_UFlat/9 165578 164480 881.8MB/s txt1 +0.7%
|
460
|
+
BM_UFlat/10 143707 144139 828.2MB/s txt2 -0.3%
|
461
|
+
BM_UFlat/11 443026 436281 932.8MB/s txt3 +1.5%
|
462
|
+
BM_UFlat/12 603129 595856 771.2MB/s txt4 +1.2%
|
463
|
+
BM_UFlat/13 271682 270450 1.8GB/s bin +0.5%
|
464
|
+
BM_UFlat/14 26200 25666 1.4GB/s sum +2.1%
|
465
|
+
BM_UFlat/15 2620 2608 1.5GB/s man +0.5%
|
466
|
+
BM_UFlat/16 48908 47756 2.3GB/s pb +2.4%
|
467
|
+
BM_UFlat/17 174638 170346 1031.9MB/s gaviota +2.5%
|
468
|
+
BM_UValidate/0 31922 31898 3.0GB/s html +0.1%
|
469
|
+
BM_UValidate/1 341265 363554 1.8GB/s urls -6.1%
|
470
|
+
BM_UValidate/2 160 151 782.8GB/s jpg +6.0%
|
471
|
+
BM_UValidate/3 10402 10380 8.5GB/s pdf +0.2%
|
472
|
+
BM_UValidate/4 129490 130587 2.9GB/s html4 -0.8%
|
473
|
+
BM_UDataBuffer/0 59383 58736 1.6GB/s html +1.1%
|
474
|
+
BM_UDataBuffer/1 619222 637786 1049.8MB/s urls -2.9%
|
475
|
+
BM_UDataBuffer/2 10775 11941 9.9GB/s jpg -9.8%
|
476
|
+
BM_UDataBuffer/3 18002 17930 4.9GB/s pdf +0.4%
|
477
|
+
BM_UDataBuffer/4 259182 259306 1.5GB/s html4 -0.0%
|
478
|
+
BM_UCord/0 59379 57814 1.6GB/s html +2.7%
|
479
|
+
BM_UCord/1 598456 615162 1088.4MB/s urls -2.7%
|
480
|
+
BM_UCord/2 8519 8628 13.7GB/s jpg -1.3%
|
481
|
+
BM_UCord/3 18123 17537 5.0GB/s pdf +3.3%
|
482
|
+
BM_UCord/4 252375 252331 1.5GB/s html4 +0.0%
|
483
|
+
BM_UCordString/0 49494 49790 1.9GB/s html -0.6%
|
484
|
+
BM_UCordString/1 524659 541803 1.2GB/s urls -3.2%
|
485
|
+
BM_UCordString/2 8206 8354 14.2GB/s jpg -1.8%
|
486
|
+
BM_UCordString/3 17235 16537 5.3GB/s pdf +4.2%
|
487
|
+
BM_UCordString/4 210188 211072 1.8GB/s html4 -0.4%
|
488
|
+
BM_UCordValidate/0 31956 31587 3.0GB/s html +1.2%
|
489
|
+
BM_UCordValidate/1 340828 362141 1.8GB/s urls -5.9%
|
490
|
+
BM_UCordValidate/2 783 744 158.9GB/s jpg +5.2%
|
491
|
+
BM_UCordValidate/3 10543 10462 8.4GB/s pdf +0.8%
|
492
|
+
BM_UCordValidate/4 130150 129789 2.9GB/s html4 +0.3%
|
493
|
+
BM_ZFlat/0 113873 111200 878.2MB/s html (22.31 %) +2.4%
|
494
|
+
BM_ZFlat/1 1473023 1489858 449.4MB/s urls (47.77 %) -1.1%
|
495
|
+
BM_ZFlat/2 23569 19486 6.1GB/s jpg (99.87 %) +21.0%
|
496
|
+
BM_ZFlat/3 49178 48046 1.8GB/s pdf (82.07 %) +2.4%
|
497
|
+
BM_ZFlat/4 475063 469394 832.2MB/s html4 (22.51 %) +1.2%
|
498
|
+
BM_ZFlat/5 46910 46816 501.2MB/s cp (48.12 %) +0.2%
|
499
|
+
BM_ZFlat/6 16883 16916 628.6MB/s c (42.40 %) -0.2%
|
500
|
+
BM_ZFlat/7 5381 5447 651.5MB/s lsp (48.37 %) -1.2%
|
501
|
+
BM_ZFlat/8 1466870 1473861 666.3MB/s xls (41.23 %) -0.5%
|
502
|
+
BM_ZFlat/9 468006 464101 312.5MB/s txt1 (57.87 %) +0.8%
|
503
|
+
BM_ZFlat/10 408157 408957 291.9MB/s txt2 (61.93 %) -0.2%
|
504
|
+
BM_ZFlat/11 1253348 1232910 330.1MB/s txt3 (54.92 %) +1.7%
|
505
|
+
BM_ZFlat/12 1702373 1702977 269.8MB/s txt4 (66.22 %) -0.0%
|
506
|
+
BM_ZFlat/13 439792 438557 1116.0MB/s bin (18.11 %) +0.3%
|
507
|
+
BM_ZFlat/14 80766 78851 462.5MB/s sum (48.96 %) +2.4%
|
508
|
+
BM_ZFlat/15 7420 7542 534.5MB/s man (59.36 %) -1.6%
|
509
|
+
BM_ZFlat/16 112043 100126 1.1GB/s pb (19.64 %) +11.9%
|
510
|
+
BM_ZFlat/17 368877 357703 491.4MB/s gaviota (37.72 %) +3.1%
|
511
|
+
BM_ZCord/0 116402 113564 859.9MB/s html +2.5%
|
512
|
+
BM_ZCord/1 1507156 1519911 440.5MB/s urls -0.8%
|
513
|
+
BM_ZCord/2 39860 33686 3.5GB/s jpg +18.3%
|
514
|
+
BM_ZCord/3 56211 54694 1.6GB/s pdf +2.8%
|
515
|
+
BM_ZCord/4 485594 479212 815.1MB/s html4 +1.3%
|
516
|
+
BM_ZDataBuffer/0 123185 121572 803.3MB/s html +1.3%
|
517
|
+
BM_ZDataBuffer/1 1569111 1589380 421.3MB/s urls -1.3%
|
518
|
+
BM_ZDataBuffer/2 53143 49556 2.4GB/s jpg +7.2%
|
519
|
+
BM_ZDataBuffer/3 65725 66826 1.3GB/s pdf -1.6%
|
520
|
+
BM_ZDataBuffer/4 517871 514750 758.9MB/s html4 +0.6%
|
521
|
+
Sum of all benchmarks 20258879 20315484 -0.3%
|
522
|
+
|
523
|
+
|
524
|
+
AMD Instanbul 2.4 GHz:
|
525
|
+
|
526
|
+
Benchmark Base (ns) New (ns) Improvement
|
527
|
+
-------------------------------------------------------------------------------------------------
|
528
|
+
BM_UFlat/0 97120 96585 1011.1MB/s html +0.6%
|
529
|
+
BM_UFlat/1 917473 948016 706.3MB/s urls -3.2%
|
530
|
+
BM_UFlat/2 21496 23938 4.9GB/s jpg -10.2%
|
531
|
+
BM_UFlat/3 44751 45639 1.9GB/s pdf -1.9%
|
532
|
+
BM_UFlat/4 391950 391413 998.0MB/s html4 +0.1%
|
533
|
+
BM_UFlat/5 37366 37201 630.7MB/s cp +0.4%
|
534
|
+
BM_UFlat/6 18350 18318 580.5MB/s c +0.2%
|
535
|
+
BM_UFlat/7 5672 5661 626.9MB/s lsp +0.2%
|
536
|
+
BM_UFlat/8 1533390 1529441 642.1MB/s xls +0.3%
|
537
|
+
BM_UFlat/9 335477 336553 431.0MB/s txt1 -0.3%
|
538
|
+
BM_UFlat/10 285140 292080 408.7MB/s txt2 -2.4%
|
539
|
+
BM_UFlat/11 888507 894758 454.9MB/s txt3 -0.7%
|
540
|
+
BM_UFlat/12 1187643 1210928 379.5MB/s txt4 -1.9%
|
541
|
+
BM_UFlat/13 493717 507447 964.5MB/s bin -2.7%
|
542
|
+
BM_UFlat/14 61740 60870 599.1MB/s sum +1.4%
|
543
|
+
BM_UFlat/15 7211 7187 560.9MB/s man +0.3%
|
544
|
+
BM_UFlat/16 97435 93100 1.2GB/s pb +4.7%
|
545
|
+
BM_UFlat/17 362662 356395 493.2MB/s gaviota +1.8%
|
546
|
+
BM_UValidate/0 47475 47118 2.0GB/s html +0.8%
|
547
|
+
BM_UValidate/1 501304 529741 1.2GB/s urls -5.4%
|
548
|
+
BM_UValidate/2 276 243 486.2GB/s jpg +13.6%
|
549
|
+
BM_UValidate/3 16361 16261 5.4GB/s pdf +0.6%
|
550
|
+
BM_UValidate/4 190741 190353 2.0GB/s html4 +0.2%
|
551
|
+
BM_UDataBuffer/0 111080 109771 889.6MB/s html +1.2%
|
552
|
+
BM_UDataBuffer/1 1051035 1085999 616.5MB/s urls -3.2%
|
553
|
+
BM_UDataBuffer/2 25801 25463 4.6GB/s jpg +1.3%
|
554
|
+
BM_UDataBuffer/3 50493 49946 1.8GB/s pdf +1.1%
|
555
|
+
BM_UDataBuffer/4 447258 444138 879.5MB/s html4 +0.7%
|
556
|
+
BM_UCord/0 109350 107909 905.0MB/s html +1.3%
|
557
|
+
BM_UCord/1 1023396 1054964 634.7MB/s urls -3.0%
|
558
|
+
BM_UCord/2 25292 24371 4.9GB/s jpg +3.8%
|
559
|
+
BM_UCord/3 48955 49736 1.8GB/s pdf -1.6%
|
560
|
+
BM_UCord/4 440452 437331 893.2MB/s html4 +0.7%
|
561
|
+
BM_UCordString/0 98511 98031 996.2MB/s html +0.5%
|
562
|
+
BM_UCordString/1 933230 963495 694.9MB/s urls -3.1%
|
563
|
+
BM_UCordString/2 23311 24076 4.9GB/s jpg -3.2%
|
564
|
+
BM_UCordString/3 45568 46196 1.9GB/s pdf -1.4%
|
565
|
+
BM_UCordString/4 397791 396934 984.1MB/s html4 +0.2%
|
566
|
+
BM_UCordValidate/0 47537 46921 2.0GB/s html +1.3%
|
567
|
+
BM_UCordValidate/1 505071 532716 1.2GB/s urls -5.2%
|
568
|
+
BM_UCordValidate/2 1663 1621 72.9GB/s jpg +2.6%
|
569
|
+
BM_UCordValidate/3 16890 16926 5.2GB/s pdf -0.2%
|
570
|
+
BM_UCordValidate/4 192365 191984 2.0GB/s html4 +0.2%
|
571
|
+
BM_ZFlat/0 184708 179103 545.3MB/s html (22.31 %) +3.1%
|
572
|
+
BM_ZFlat/1 2293864 2302950 290.7MB/s urls (47.77 %) -0.4%
|
573
|
+
BM_ZFlat/2 52852 47618 2.5GB/s jpg (99.87 %) +11.0%
|
574
|
+
BM_ZFlat/3 100766 96179 935.3MB/s pdf (82.07 %) +4.8%
|
575
|
+
BM_ZFlat/4 741220 727977 536.6MB/s html4 (22.51 %) +1.8%
|
576
|
+
BM_ZFlat/5 85402 85418 274.7MB/s cp (48.12 %) -0.0%
|
577
|
+
BM_ZFlat/6 36558 36494 291.4MB/s c (42.40 %) +0.2%
|
578
|
+
BM_ZFlat/7 12706 12507 283.7MB/s lsp (48.37 %) +1.6%
|
579
|
+
BM_ZFlat/8 2336823 2335688 420.5MB/s xls (41.23 %) +0.0%
|
580
|
+
BM_ZFlat/9 701804 681153 212.9MB/s txt1 (57.87 %) +3.0%
|
581
|
+
BM_ZFlat/10 606700 597194 199.9MB/s txt2 (61.93 %) +1.6%
|
582
|
+
BM_ZFlat/11 1852283 1803238 225.7MB/s txt3 (54.92 %) +2.7%
|
583
|
+
BM_ZFlat/12 2475527 2443354 188.1MB/s txt4 (66.22 %) +1.3%
|
584
|
+
BM_ZFlat/13 694497 696654 702.6MB/s bin (18.11 %) -0.3%
|
585
|
+
BM_ZFlat/14 136929 129855 280.8MB/s sum (48.96 %) +5.4%
|
586
|
+
BM_ZFlat/15 17172 17124 235.4MB/s man (59.36 %) +0.3%
|
587
|
+
BM_ZFlat/16 190364 171763 658.4MB/s pb (19.64 %) +10.8%
|
588
|
+
BM_ZFlat/17 567285 555190 316.6MB/s gaviota (37.72 %) +2.2%
|
589
|
+
BM_ZCord/0 193490 187031 522.1MB/s html +3.5%
|
590
|
+
BM_ZCord/1 2427537 2415315 277.2MB/s urls +0.5%
|
591
|
+
BM_ZCord/2 85378 81412 1.5GB/s jpg +4.9%
|
592
|
+
BM_ZCord/3 121898 119419 753.3MB/s pdf +2.1%
|
593
|
+
BM_ZCord/4 779564 762961 512.0MB/s html4 +2.2%
|
594
|
+
BM_ZDataBuffer/0 213820 207272 471.1MB/s html +3.2%
|
595
|
+
BM_ZDataBuffer/1 2589010 2586495 258.9MB/s urls +0.1%
|
596
|
+
BM_ZDataBuffer/2 121871 118885 1018.4MB/s jpg +2.5%
|
597
|
+
BM_ZDataBuffer/3 145382 145986 616.2MB/s pdf -0.4%
|
598
|
+
BM_ZDataBuffer/4 868117 852754 458.1MB/s html4 +1.8%
|
599
|
+
Sum of all benchmarks 33771833 33744763 +0.1%
|
600
|
+
|
601
|
+
------------------------------------------------------------------------
|
602
|
+
r70 | snappy.mirrorbot@gmail.com | 2013-01-06 20:21:26 +0100 (Sun, 06 Jan 2013) | 6 lines
|
603
|
+
|
604
|
+
Adjust the Snappy open-source distribution for the changes in Google's
|
605
|
+
internal file API.
|
606
|
+
|
607
|
+
R=sanjay
|
608
|
+
|
609
|
+
|
610
|
+
------------------------------------------------------------------------
|
611
|
+
r69 | snappy.mirrorbot@gmail.com | 2013-01-04 12:54:20 +0100 (Fri, 04 Jan 2013) | 15 lines
|
612
|
+
|
613
|
+
Change a few ORs to additions where they don't matter. This helps the compiler
|
614
|
+
use the LEA instruction more efficiently, since e.g. a + (b << 2) can be encoded
|
615
|
+
as one instruction. Even more importantly, it can constant-fold the
|
616
|
+
COPY_* enums together with the shifted negative constants, which also saves
|
617
|
+
some instructions. (We don't need it for LITERAL, since it happens to be 0.)
|
618
|
+
|
619
|
+
I am unsure why the compiler couldn't do this itself, but the theory is that
|
620
|
+
it cannot prove that len-1 and len-4 cannot underflow/wrap, and thus can't
|
621
|
+
do the optimization safely.
|
622
|
+
|
623
|
+
The gains are small but measurable; 0.5-1.0% over the BM_Z* benchmarks
|
624
|
+
(measured on Westmere, Sandy Bridge and Istanbul).
|
625
|
+
|
626
|
+
R=sanjay
|
627
|
+
|
628
|
+
------------------------------------------------------------------------
|
629
|
+
r68 | snappy.mirrorbot@gmail.com | 2012-10-08 13:37:16 +0200 (Mon, 08 Oct 2012) | 5 lines
|
630
|
+
|
631
|
+
Stop giving -Werror to automake, due to an incompatibility between current
|
632
|
+
versions of libtool and automake on non-GNU platforms (e.g. Mac OS X).
|
633
|
+
|
634
|
+
R=sanjay
|
635
|
+
|
636
|
+
------------------------------------------------------------------------
|
637
|
+
r67 | snappy.mirrorbot@gmail.com | 2012-08-17 15:54:47 +0200 (Fri, 17 Aug 2012) | 5 lines
|
638
|
+
|
639
|
+
Fix public issue 66: Document GetUncompressedLength better, in particular that
|
640
|
+
it leaves the source in a state that's not appropriate for RawUncompress.
|
641
|
+
|
642
|
+
R=sanjay
|
643
|
+
|
644
|
+
------------------------------------------------------------------------
|
645
|
+
r66 | snappy.mirrorbot@gmail.com | 2012-07-31 13:44:44 +0200 (Tue, 31 Jul 2012) | 5 lines
|
646
|
+
|
647
|
+
Fix public issue 64: Check for <sys/time.h> at configure time,
|
648
|
+
since MSVC seemingly does not have it.
|
649
|
+
|
650
|
+
R=sanjay
|
651
|
+
|
652
|
+
------------------------------------------------------------------------
|
653
|
+
r65 | snappy.mirrorbot@gmail.com | 2012-07-04 11:34:48 +0200 (Wed, 04 Jul 2012) | 10 lines
|
654
|
+
|
655
|
+
Handle the case where gettimeofday() goes backwards or returns the same value
|
656
|
+
twice; it could cause division by zero in the unit test framework.
|
657
|
+
(We already had one fix for this in place, but it was incomplete.)
|
658
|
+
|
659
|
+
This could in theory happen on any system, since there are few guarantees
|
660
|
+
about gettimeofday(), but seems to only happen in practice on GNU/Hurd, where
|
661
|
+
gettimeofday() is cached and only updated ever so often.
|
662
|
+
|
663
|
+
R=sanjay
|
664
|
+
|
665
|
+
------------------------------------------------------------------------
|
666
|
+
r64 | snappy.mirrorbot@gmail.com | 2012-07-04 11:28:33 +0200 (Wed, 04 Jul 2012) | 6 lines
|
667
|
+
|
668
|
+
Mark ARMv4 as not supporting unaligned accesses (not just ARMv5 and ARMv6);
|
669
|
+
apparently Debian still targets these by default, giving us segfaults on
|
670
|
+
armel.
|
671
|
+
|
672
|
+
R=sanjay
|
673
|
+
|
674
|
+
------------------------------------------------------------------------
|
675
|
+
r63 | snappy.mirrorbot@gmail.com | 2012-05-22 11:46:05 +0200 (Tue, 22 May 2012) | 5 lines
|
676
|
+
|
677
|
+
Fix public bug #62: Remove an extraneous comma at the end of an enum list,
|
678
|
+
causing compile errors when embedded in Mozilla on OpenBSD.
|
679
|
+
|
680
|
+
R=sanjay
|
681
|
+
|
682
|
+
------------------------------------------------------------------------
|
683
|
+
r62 | snappy.mirrorbot@gmail.com | 2012-05-22 11:32:50 +0200 (Tue, 22 May 2012) | 8 lines
|
684
|
+
|
685
|
+
Snappy library no longer depends on iostream.
|
686
|
+
|
687
|
+
Achieved by moving logging macro definitions to a test-only
|
688
|
+
header file, and by changing non-test code to use assert,
|
689
|
+
fprintf, and abort instead of LOG/CHECK macros.
|
690
|
+
|
691
|
+
R=sesse
|
692
|
+
|
693
|
+
------------------------------------------------------------------------
|
694
|
+
r61 | snappy.mirrorbot@gmail.com | 2012-02-24 16:46:37 +0100 (Fri, 24 Feb 2012) | 4 lines
|
695
|
+
|
696
|
+
Release Snappy 1.0.5.
|
697
|
+
|
698
|
+
R=sanjay
|
699
|
+
|
700
|
+
------------------------------------------------------------------------
|
701
|
+
r60 | snappy.mirrorbot@gmail.com | 2012-02-23 18:00:36 +0100 (Thu, 23 Feb 2012) | 57 lines
|
702
|
+
|
703
|
+
For 32-bit platforms, do not try to accelerate multiple neighboring
|
704
|
+
32-bit loads with a 64-bit load during compression (it's not a win).
|
705
|
+
|
706
|
+
The main target for this optimization is ARM, but 32-bit x86 gets
|
707
|
+
a small gain, too, although there is noise in the microbenchmarks.
|
708
|
+
It's a no-op for 64-bit x86. It does not affect decompression.
|
709
|
+
|
710
|
+
Microbenchmark results on a Cortex-A9 1GHz, using g++ 4.6.2 (from
|
711
|
+
Ubuntu/Linaro), -O2 -DNDEBUG -Wa,-march=armv7a -mtune=cortex-a9
|
712
|
+
-mthumb-interwork, minimum 1000 iterations:
|
713
|
+
|
714
|
+
Benchmark Time(ns) CPU(ns) Iterations
|
715
|
+
---------------------------------------------------
|
716
|
+
BM_ZFlat/0 1158277 1160000 1000 84.2MB/s html (23.57 %) [ +4.3%]
|
717
|
+
BM_ZFlat/1 14861782 14860000 1000 45.1MB/s urls (50.89 %) [ +1.1%]
|
718
|
+
BM_ZFlat/2 393595 390000 1000 310.5MB/s jpg (99.88 %) [ +0.0%]
|
719
|
+
BM_ZFlat/3 650583 650000 1000 138.4MB/s pdf (82.13 %) [ +3.1%]
|
720
|
+
BM_ZFlat/4 4661480 4660000 1000 83.8MB/s html4 (23.55 %) [ +4.3%]
|
721
|
+
BM_ZFlat/5 491973 490000 1000 47.9MB/s cp (48.12 %) [ +2.0%]
|
722
|
+
BM_ZFlat/6 193575 192678 1038 55.2MB/s c (42.40 %) [ +9.0%]
|
723
|
+
BM_ZFlat/7 62343 62754 3187 56.5MB/s lsp (48.37 %) [ +2.6%]
|
724
|
+
BM_ZFlat/8 17708468 17710000 1000 55.5MB/s xls (41.34 %) [ -0.3%]
|
725
|
+
BM_ZFlat/9 3755345 3760000 1000 38.6MB/s txt1 (59.81 %) [ +8.2%]
|
726
|
+
BM_ZFlat/10 3324217 3320000 1000 36.0MB/s txt2 (64.07 %) [ +4.2%]
|
727
|
+
BM_ZFlat/11 10139932 10140000 1000 40.1MB/s txt3 (57.11 %) [ +6.4%]
|
728
|
+
BM_ZFlat/12 13532109 13530000 1000 34.0MB/s txt4 (68.35 %) [ +5.0%]
|
729
|
+
BM_ZFlat/13 4690847 4690000 1000 104.4MB/s bin (18.21 %) [ +4.1%]
|
730
|
+
BM_ZFlat/14 830682 830000 1000 43.9MB/s sum (51.88 %) [ +1.2%]
|
731
|
+
BM_ZFlat/15 84784 85011 2235 47.4MB/s man (59.36 %) [ +1.1%]
|
732
|
+
BM_ZFlat/16 1293254 1290000 1000 87.7MB/s pb (23.15 %) [ +2.3%]
|
733
|
+
BM_ZFlat/17 2775155 2780000 1000 63.2MB/s gaviota (38.27 %) [+12.2%]
|
734
|
+
|
735
|
+
Core i7 in 32-bit mode (only one run and 100 iterations, though, so noisy):
|
736
|
+
|
737
|
+
Benchmark Time(ns) CPU(ns) Iterations
|
738
|
+
---------------------------------------------------
|
739
|
+
BM_ZFlat/0 227582 223464 3043 437.0MB/s html (23.57 %) [ +7.4%]
|
740
|
+
BM_ZFlat/1 2982430 2918455 233 229.4MB/s urls (50.89 %) [ +2.9%]
|
741
|
+
BM_ZFlat/2 46967 46658 15217 2.5GB/s jpg (99.88 %) [ +0.0%]
|
742
|
+
BM_ZFlat/3 115298 114864 5833 783.2MB/s pdf (82.13 %) [ +1.5%]
|
743
|
+
BM_ZFlat/4 913440 899743 778 434.2MB/s html4 (23.55 %) [ +0.3%]
|
744
|
+
BM_ZFlat/5 110302 108571 7000 216.1MB/s cp (48.12 %) [ +0.0%]
|
745
|
+
BM_ZFlat/6 44409 43372 15909 245.2MB/s c (42.40 %) [ +0.8%]
|
746
|
+
BM_ZFlat/7 15713 15643 46667 226.9MB/s lsp (48.37 %) [ +2.7%]
|
747
|
+
BM_ZFlat/8 2625539 2602230 269 377.4MB/s xls (41.34 %) [ +1.4%]
|
748
|
+
BM_ZFlat/9 808884 811429 875 178.8MB/s txt1 (59.81 %) [ -3.9%]
|
749
|
+
BM_ZFlat/10 709532 700000 1000 170.5MB/s txt2 (64.07 %) [ +0.0%]
|
750
|
+
BM_ZFlat/11 2177682 2162162 333 188.2MB/s txt3 (57.11 %) [ -1.4%]
|
751
|
+
BM_ZFlat/12 2849640 2840000 250 161.8MB/s txt4 (68.35 %) [ -1.4%]
|
752
|
+
BM_ZFlat/13 849760 835476 778 585.8MB/s bin (18.21 %) [ +1.2%]
|
753
|
+
BM_ZFlat/14 165940 164571 4375 221.6MB/s sum (51.88 %) [ +1.4%]
|
754
|
+
BM_ZFlat/15 20939 20571 35000 196.0MB/s man (59.36 %) [ +2.1%]
|
755
|
+
BM_ZFlat/16 239209 236544 2917 478.1MB/s pb (23.15 %) [ +4.2%]
|
756
|
+
BM_ZFlat/17 616206 610000 1000 288.2MB/s gaviota (38.27 %) [ -1.6%]
|
757
|
+
|
758
|
+
R=sanjay
|
759
|
+
|
760
|
+
------------------------------------------------------------------------
|
761
|
+
r59 | snappy.mirrorbot@gmail.com | 2012-02-21 18:02:17 +0100 (Tue, 21 Feb 2012) | 107 lines
|
762
|
+
|
763
|
+
Enable the use of unaligned loads and stores for ARM-based architectures
|
764
|
+
where they are available (ARMv7 and higher). This gives a significant
|
765
|
+
speed boost on ARM, both for compression and decompression.
|
766
|
+
It should not affect x86 at all.
|
767
|
+
|
768
|
+
There are more changes possible to speed up ARM, but it might not be
|
769
|
+
that easy to do without hurting x86 or making the code uglier.
|
770
|
+
Also, we de not try to use NEON yet.
|
771
|
+
|
772
|
+
Microbenchmark results on a Cortex-A9 1GHz, using g++ 4.6.2 (from Ubuntu/Linaro),
|
773
|
+
-O2 -DNDEBUG -Wa,-march=armv7a -mtune=cortex-a9 -mthumb-interwork:
|
774
|
+
|
775
|
+
Benchmark Time(ns) CPU(ns) Iterations
|
776
|
+
---------------------------------------------------
|
777
|
+
BM_UFlat/0 524806 529100 378 184.6MB/s html [+33.6%]
|
778
|
+
BM_UFlat/1 5139790 5200000 100 128.8MB/s urls [+28.8%]
|
779
|
+
BM_UFlat/2 86540 84166 1901 1.4GB/s jpg [ +0.6%]
|
780
|
+
BM_UFlat/3 215351 210176 904 428.0MB/s pdf [+29.8%]
|
781
|
+
BM_UFlat/4 2144490 2100000 100 186.0MB/s html4 [+33.3%]
|
782
|
+
BM_UFlat/5 194482 190000 1000 123.5MB/s cp [+36.2%]
|
783
|
+
BM_UFlat/6 91843 90175 2107 117.9MB/s c [+38.6%]
|
784
|
+
BM_UFlat/7 28535 28426 6684 124.8MB/s lsp [+34.7%]
|
785
|
+
BM_UFlat/8 9206600 9200000 100 106.7MB/s xls [+42.4%]
|
786
|
+
BM_UFlat/9 1865273 1886792 106 76.9MB/s txt1 [+32.5%]
|
787
|
+
BM_UFlat/10 1576809 1587301 126 75.2MB/s txt2 [+32.3%]
|
788
|
+
BM_UFlat/11 4968450 4900000 100 83.1MB/s txt3 [+32.7%]
|
789
|
+
BM_UFlat/12 6673970 6700000 100 68.6MB/s txt4 [+32.8%]
|
790
|
+
BM_UFlat/13 2391470 2400000 100 203.9MB/s bin [+29.2%]
|
791
|
+
BM_UFlat/14 334601 344827 522 105.8MB/s sum [+30.6%]
|
792
|
+
BM_UFlat/15 37404 38080 5252 105.9MB/s man [+33.8%]
|
793
|
+
BM_UFlat/16 535470 540540 370 209.2MB/s pb [+31.2%]
|
794
|
+
BM_UFlat/17 1875245 1886792 106 93.2MB/s gaviota [+37.8%]
|
795
|
+
BM_UValidate/0 178425 179533 1114 543.9MB/s html [ +2.7%]
|
796
|
+
BM_UValidate/1 2100450 2000000 100 334.8MB/s urls [ +5.0%]
|
797
|
+
BM_UValidate/2 1039 1044 172413 113.3GB/s jpg [ +3.4%]
|
798
|
+
BM_UValidate/3 59423 59470 3363 1.5GB/s pdf [ +7.8%]
|
799
|
+
BM_UValidate/4 760716 766283 261 509.8MB/s html4 [ +6.5%]
|
800
|
+
BM_ZFlat/0 1204632 1204819 166 81.1MB/s html (23.57 %) [+32.8%]
|
801
|
+
BM_ZFlat/1 15656190 15600000 100 42.9MB/s urls (50.89 %) [+27.6%]
|
802
|
+
BM_ZFlat/2 403336 410677 487 294.8MB/s jpg (99.88 %) [+16.5%]
|
803
|
+
BM_ZFlat/3 664073 671140 298 134.0MB/s pdf (82.13 %) [+28.4%]
|
804
|
+
BM_ZFlat/4 4961940 4900000 100 79.7MB/s html4 (23.55 %) [+30.6%]
|
805
|
+
BM_ZFlat/5 500664 501253 399 46.8MB/s cp (48.12 %) [+33.4%]
|
806
|
+
BM_ZFlat/6 217276 215982 926 49.2MB/s c (42.40 %) [+25.0%]
|
807
|
+
BM_ZFlat/7 64122 65487 3054 54.2MB/s lsp (48.37 %) [+36.1%]
|
808
|
+
BM_ZFlat/8 18045730 18000000 100 54.6MB/s xls (41.34 %) [+34.4%]
|
809
|
+
BM_ZFlat/9 4051530 4000000 100 36.3MB/s txt1 (59.81 %) [+25.0%]
|
810
|
+
BM_ZFlat/10 3451800 3500000 100 34.1MB/s txt2 (64.07 %) [+25.7%]
|
811
|
+
BM_ZFlat/11 11052340 11100000 100 36.7MB/s txt3 (57.11 %) [+24.3%]
|
812
|
+
BM_ZFlat/12 14538690 14600000 100 31.5MB/s txt4 (68.35 %) [+24.7%]
|
813
|
+
BM_ZFlat/13 5041850 5000000 100 97.9MB/s bin (18.21 %) [+32.0%]
|
814
|
+
BM_ZFlat/14 908840 909090 220 40.1MB/s sum (51.88 %) [+22.2%]
|
815
|
+
BM_ZFlat/15 86921 86206 1972 46.8MB/s man (59.36 %) [+42.2%]
|
816
|
+
BM_ZFlat/16 1312315 1315789 152 86.0MB/s pb (23.15 %) [+34.5%]
|
817
|
+
BM_ZFlat/17 3173120 3200000 100 54.9MB/s gaviota (38.27%) [+28.1%]
|
818
|
+
|
819
|
+
|
820
|
+
The move from 64-bit to 32-bit operations for the copies also affected 32-bit x86;
|
821
|
+
positive on the decompression side, and slightly negative on the compression side
|
822
|
+
(unless that is noise; I only ran once):
|
823
|
+
|
824
|
+
Benchmark Time(ns) CPU(ns) Iterations
|
825
|
+
-----------------------------------------------------
|
826
|
+
BM_UFlat/0 86279 86140 7778 1.1GB/s html [ +7.5%]
|
827
|
+
BM_UFlat/1 839265 822622 778 813.9MB/s urls [ +9.4%]
|
828
|
+
BM_UFlat/2 9180 9143 87500 12.9GB/s jpg [ +1.2%]
|
829
|
+
BM_UFlat/3 35080 35000 20000 2.5GB/s pdf [+10.1%]
|
830
|
+
BM_UFlat/4 350318 345000 2000 1.1GB/s html4 [ +7.0%]
|
831
|
+
BM_UFlat/5 33808 33472 21212 701.0MB/s cp [ +9.0%]
|
832
|
+
BM_UFlat/6 15201 15214 46667 698.9MB/s c [+14.9%]
|
833
|
+
BM_UFlat/7 4652 4651 159091 762.9MB/s lsp [ +7.5%]
|
834
|
+
BM_UFlat/8 1285551 1282528 538 765.7MB/s xls [+10.7%]
|
835
|
+
BM_UFlat/9 282510 281690 2414 514.9MB/s txt1 [+13.6%]
|
836
|
+
BM_UFlat/10 243494 239286 2800 498.9MB/s txt2 [+14.4%]
|
837
|
+
BM_UFlat/11 743625 740000 1000 550.0MB/s txt3 [+14.3%]
|
838
|
+
BM_UFlat/12 999441 989717 778 464.3MB/s txt4 [+16.1%]
|
839
|
+
BM_UFlat/13 412402 410076 1707 1.2GB/s bin [ +7.3%]
|
840
|
+
BM_UFlat/14 54876 54000 10000 675.3MB/s sum [+13.0%]
|
841
|
+
BM_UFlat/15 6146 6100 100000 660.8MB/s man [+14.8%]
|
842
|
+
BM_UFlat/16 90496 90286 8750 1.2GB/s pb [ +4.0%]
|
843
|
+
BM_UFlat/17 292650 292000 2500 602.0MB/s gaviota [+18.1%]
|
844
|
+
BM_UValidate/0 49620 49699 14286 1.9GB/s html [ +0.0%]
|
845
|
+
BM_UValidate/1 501371 500000 1000 1.3GB/s urls [ +0.0%]
|
846
|
+
BM_UValidate/2 232 227 3043478 521.5GB/s jpg [ +1.3%]
|
847
|
+
BM_UValidate/3 17250 17143 43750 5.1GB/s pdf [ -1.3%]
|
848
|
+
BM_UValidate/4 198643 200000 3500 1.9GB/s html4 [ -0.9%]
|
849
|
+
BM_ZFlat/0 227128 229415 3182 425.7MB/s html (23.57 %) [ -1.4%]
|
850
|
+
BM_ZFlat/1 2970089 2960000 250 226.2MB/s urls (50.89 %) [ -1.9%]
|
851
|
+
BM_ZFlat/2 45683 44999 15556 2.6GB/s jpg (99.88 %) [ +2.2%]
|
852
|
+
BM_ZFlat/3 114661 113136 6364 795.1MB/s pdf (82.13 %) [ -1.5%]
|
853
|
+
BM_ZFlat/4 919702 914286 875 427.2MB/s html4 (23.55%) [ -1.3%]
|
854
|
+
BM_ZFlat/5 108189 108422 6364 216.4MB/s cp (48.12 %) [ -1.2%]
|
855
|
+
BM_ZFlat/6 44525 44000 15909 241.7MB/s c (42.40 %) [ -2.9%]
|
856
|
+
BM_ZFlat/7 15973 15857 46667 223.8MB/s lsp (48.37 %) [ +0.0%]
|
857
|
+
BM_ZFlat/8 2677888 2639405 269 372.1MB/s xls (41.34 %) [ -1.4%]
|
858
|
+
BM_ZFlat/9 800715 780000 1000 186.0MB/s txt1 (59.81 %) [ -0.4%]
|
859
|
+
BM_ZFlat/10 700089 700000 1000 170.5MB/s txt2 (64.07 %) [ -2.9%]
|
860
|
+
BM_ZFlat/11 2159356 2138365 318 190.3MB/s txt3 (57.11 %) [ -0.3%]
|
861
|
+
BM_ZFlat/12 2796143 2779923 259 165.3MB/s txt4 (68.35 %) [ -1.4%]
|
862
|
+
BM_ZFlat/13 856458 835476 778 585.8MB/s bin (18.21 %) [ -0.1%]
|
863
|
+
BM_ZFlat/14 166908 166857 4375 218.6MB/s sum (51.88 %) [ -1.4%]
|
864
|
+
BM_ZFlat/15 21181 20857 35000 193.3MB/s man (59.36 %) [ -0.8%]
|
865
|
+
BM_ZFlat/16 244009 239973 2917 471.3MB/s pb (23.15 %) [ -1.4%]
|
866
|
+
BM_ZFlat/17 596362 590000 1000 297.9MB/s gaviota (38.27%) [ +0.0%]
|
867
|
+
|
868
|
+
R=sanjay
|
869
|
+
|
870
|
+
------------------------------------------------------------------------
|
871
|
+
r58 | snappy.mirrorbot@gmail.com | 2012-02-11 23:11:22 +0100 (Sat, 11 Feb 2012) | 9 lines
|
872
|
+
|
873
|
+
Lower the size allocated in the "corrupted input" unit test from 256 MB
|
874
|
+
to 2 MB. This fixes issues with running the unit test on platforms with
|
875
|
+
little RAM (e.g. some ARM boards).
|
876
|
+
|
877
|
+
Also, reactivate the 2 MB test for 64-bit platforms; there's no good
|
878
|
+
reason why it shouldn't be.
|
879
|
+
|
880
|
+
R=sanjay
|
881
|
+
|
882
|
+
------------------------------------------------------------------------
|
883
|
+
r57 | snappy.mirrorbot@gmail.com | 2012-01-08 18:55:48 +0100 (Sun, 08 Jan 2012) | 2 lines
|
884
|
+
|
885
|
+
Minor refactoring to accomodate changes in Google's internal code tree.
|
886
|
+
|
887
|
+
------------------------------------------------------------------------
|
888
|
+
r56 | snappy.mirrorbot@gmail.com | 2012-01-04 14:10:46 +0100 (Wed, 04 Jan 2012) | 19 lines
|
889
|
+
|
890
|
+
Fix public issue r57: Fix most warnings with -Wall, mostly signed/unsigned
|
891
|
+
warnings. There are still some in the unit test, but the main .cc file should
|
892
|
+
be clean. We haven't enabled -Wall for the default build, since the unit test
|
893
|
+
is still not clean.
|
894
|
+
|
895
|
+
This also fixes a real bug in the open-source implementation of
|
896
|
+
ReadFileToStringOrDie(); it would not detect errors correctly.
|
897
|
+
|
898
|
+
I had to go through some pains to avoid performance loss as the types
|
899
|
+
were changed; I think there might still be some with 32-bit if and only if LFS
|
900
|
+
is enabled (ie., size_t is 64-bit), but for regular 32-bit and 64-bit I can't
|
901
|
+
see any losses, and I've diffed the generated GCC assembler between the old and
|
902
|
+
new code without seeing any significant choices. If anything, it's ever so
|
903
|
+
slightly faster.
|
904
|
+
|
905
|
+
This may or may not enable compression of very large blocks (>2^32 bytes)
|
906
|
+
when size_t is 64-bit, but I haven't checked, and it is still not a supported
|
907
|
+
case.
|
908
|
+
|
909
|
+
------------------------------------------------------------------------
|
910
|
+
r55 | snappy.mirrorbot@gmail.com | 2012-01-04 11:46:39 +0100 (Wed, 04 Jan 2012) | 6 lines
|
911
|
+
|
912
|
+
Add a framing format description. We do not have any implementation of this at
|
913
|
+
the current point, but there seems to be enough of a general interest in the
|
914
|
+
topic (cf. public bug #34).
|
915
|
+
|
916
|
+
R=csilvers,sanjay
|
917
|
+
|
918
|
+
------------------------------------------------------------------------
|
919
|
+
r54 | snappy.mirrorbot@gmail.com | 2011-12-05 22:27:26 +0100 (Mon, 05 Dec 2011) | 81 lines
|
920
|
+
|
921
|
+
Speed up decompression by moving the refill check to the end of the loop.
|
922
|
+
|
923
|
+
This seems to work because in most of the branches, the compiler can evaluate
|
924
|
+
“ip_limit_ - ip” in a more efficient way than reloading ip_limit_ from memory
|
925
|
+
(either by already having the entire expression in a register, or reconstructing
|
926
|
+
it from “avail”, or something else). Memory loads, even from L1, are seemingly
|
927
|
+
costly in the big picture at the current decompression speeds.
|
928
|
+
|
929
|
+
Microbenchmarks (64-bit, opt mode):
|
930
|
+
|
931
|
+
Westmere (Intel Core i7):
|
932
|
+
|
933
|
+
Benchmark Time(ns) CPU(ns) Iterations
|
934
|
+
--------------------------------------------
|
935
|
+
BM_UFlat/0 74492 74491 187894 1.3GB/s html [ +5.9%]
|
936
|
+
BM_UFlat/1 712268 712263 19644 940.0MB/s urls [ +3.8%]
|
937
|
+
BM_UFlat/2 10591 10590 1000000 11.2GB/s jpg [ -6.8%]
|
938
|
+
BM_UFlat/3 29643 29643 469915 3.0GB/s pdf [ +7.9%]
|
939
|
+
BM_UFlat/4 304669 304667 45930 1.3GB/s html4 [ +4.8%]
|
940
|
+
BM_UFlat/5 28508 28507 490077 823.1MB/s cp [ +4.0%]
|
941
|
+
BM_UFlat/6 12415 12415 1000000 856.5MB/s c [ +8.6%]
|
942
|
+
BM_UFlat/7 3415 3415 4084723 1039.0MB/s lsp [+18.0%]
|
943
|
+
BM_UFlat/8 979569 979563 14261 1002.5MB/s xls [ +5.8%]
|
944
|
+
BM_UFlat/9 230150 230148 60934 630.2MB/s txt1 [ +5.2%]
|
945
|
+
BM_UFlat/10 197167 197166 71135 605.5MB/s txt2 [ +4.7%]
|
946
|
+
BM_UFlat/11 607394 607390 23041 670.1MB/s txt3 [ +5.6%]
|
947
|
+
BM_UFlat/12 808502 808496 17316 568.4MB/s txt4 [ +5.0%]
|
948
|
+
BM_UFlat/13 372791 372788 37564 1.3GB/s bin [ +3.3%]
|
949
|
+
BM_UFlat/14 44541 44541 313969 818.8MB/s sum [ +5.7%]
|
950
|
+
BM_UFlat/15 4833 4833 2898697 834.1MB/s man [ +4.8%]
|
951
|
+
BM_UFlat/16 79855 79855 175356 1.4GB/s pb [ +4.8%]
|
952
|
+
BM_UFlat/17 245845 245843 56838 715.0MB/s gaviota [ +5.8%]
|
953
|
+
|
954
|
+
Clovertown (Intel Core 2):
|
955
|
+
|
956
|
+
Benchmark Time(ns) CPU(ns) Iterations
|
957
|
+
--------------------------------------------
|
958
|
+
BM_UFlat/0 107911 107890 100000 905.1MB/s html [ +2.2%]
|
959
|
+
BM_UFlat/1 1011237 1011041 10000 662.3MB/s urls [ +2.5%]
|
960
|
+
BM_UFlat/2 26775 26770 523089 4.4GB/s jpg [ +0.0%]
|
961
|
+
BM_UFlat/3 48103 48095 290618 1.8GB/s pdf [ +3.4%]
|
962
|
+
BM_UFlat/4 437724 437644 31937 892.6MB/s html4 [ +2.1%]
|
963
|
+
BM_UFlat/5 39607 39600 358284 592.5MB/s cp [ +2.4%]
|
964
|
+
BM_UFlat/6 18227 18224 768191 583.5MB/s c [ +2.7%]
|
965
|
+
BM_UFlat/7 5171 5170 2709437 686.4MB/s lsp [ +3.9%]
|
966
|
+
BM_UFlat/8 1560291 1559989 8970 629.5MB/s xls [ +3.6%]
|
967
|
+
BM_UFlat/9 335401 335343 41731 432.5MB/s txt1 [ +3.0%]
|
968
|
+
BM_UFlat/10 287014 286963 48758 416.0MB/s txt2 [ +2.8%]
|
969
|
+
BM_UFlat/11 888522 888356 15752 458.1MB/s txt3 [ +2.9%]
|
970
|
+
BM_UFlat/12 1186600 1186378 10000 387.3MB/s txt4 [ +3.1%]
|
971
|
+
BM_UFlat/13 572295 572188 24468 855.4MB/s bin [ +2.1%]
|
972
|
+
BM_UFlat/14 64060 64049 218401 569.4MB/s sum [ +4.1%]
|
973
|
+
BM_UFlat/15 7264 7263 1916168 555.0MB/s man [ +1.4%]
|
974
|
+
BM_UFlat/16 108853 108836 100000 1039.1MB/s pb [ +1.7%]
|
975
|
+
BM_UFlat/17 364289 364223 38419 482.6MB/s gaviota [ +4.9%]
|
976
|
+
|
977
|
+
Barcelona (AMD Opteron):
|
978
|
+
|
979
|
+
Benchmark Time(ns) CPU(ns) Iterations
|
980
|
+
--------------------------------------------
|
981
|
+
BM_UFlat/0 103900 103871 100000 940.2MB/s html [ +8.3%]
|
982
|
+
BM_UFlat/1 1000435 1000107 10000 669.5MB/s urls [ +6.6%]
|
983
|
+
BM_UFlat/2 24659 24652 567362 4.8GB/s jpg [ +0.1%]
|
984
|
+
BM_UFlat/3 48206 48193 291121 1.8GB/s pdf [ +5.0%]
|
985
|
+
BM_UFlat/4 421980 421850 33174 926.0MB/s html4 [ +7.3%]
|
986
|
+
BM_UFlat/5 40368 40357 346994 581.4MB/s cp [ +8.7%]
|
987
|
+
BM_UFlat/6 19836 19830 708695 536.2MB/s c [ +8.0%]
|
988
|
+
BM_UFlat/7 6100 6098 2292774 581.9MB/s lsp [ +9.0%]
|
989
|
+
BM_UFlat/8 1693093 1692514 8261 580.2MB/s xls [ +8.0%]
|
990
|
+
BM_UFlat/9 365991 365886 38225 396.4MB/s txt1 [ +7.1%]
|
991
|
+
BM_UFlat/10 311330 311238 44950 383.6MB/s txt2 [ +7.6%]
|
992
|
+
BM_UFlat/11 975037 974737 14376 417.5MB/s txt3 [ +6.9%]
|
993
|
+
BM_UFlat/12 1303558 1303175 10000 352.6MB/s txt4 [ +7.3%]
|
994
|
+
BM_UFlat/13 517448 517290 27144 946.2MB/s bin [ +5.5%]
|
995
|
+
BM_UFlat/14 66537 66518 210352 548.3MB/s sum [ +7.5%]
|
996
|
+
BM_UFlat/15 7976 7974 1760383 505.6MB/s man [ +5.6%]
|
997
|
+
BM_UFlat/16 103121 103092 100000 1097.0MB/s pb [ +8.7%]
|
998
|
+
BM_UFlat/17 391431 391314 35733 449.2MB/s gaviota [ +6.5%]
|
999
|
+
|
1000
|
+
R=sanjay
|
1001
|
+
|
1002
|
+
------------------------------------------------------------------------
|
1003
|
+
r53 | snappy.mirrorbot@gmail.com | 2011-11-23 12:14:17 +0100 (Wed, 23 Nov 2011) | 88 lines
|
1004
|
+
|
1005
|
+
Speed up decompression by making the fast path for literals faster.
|
1006
|
+
|
1007
|
+
We do the fast-path step as soon as possible; in fact, as soon as we know the
|
1008
|
+
literal length. Since we usually hit the fast path, we can then skip the checks
|
1009
|
+
for long literals and available input space (beyond what the fast path check
|
1010
|
+
already does).
|
1011
|
+
|
1012
|
+
Note that this changes the decompression Writer API; however, it does not
|
1013
|
+
change the ABI, since writers are always templatized and as such never
|
1014
|
+
cross compilation units. The new API is slightly more general, in that it
|
1015
|
+
doesn't hard-code the value 16. Note that we also take care to check
|
1016
|
+
for len <= 16 first, since the other two checks almost always succeed
|
1017
|
+
(so we don't want to waste time checking for them until we have to).
|
1018
|
+
|
1019
|
+
The improvements are most marked on Nehalem, but are generally positive
|
1020
|
+
on other platforms as well. All microbenchmarks are 64-bit, opt.
|
1021
|
+
|
1022
|
+
Clovertown (Core 2):
|
1023
|
+
|
1024
|
+
Benchmark Time(ns) CPU(ns) Iterations
|
1025
|
+
--------------------------------------------
|
1026
|
+
BM_UFlat/0 110226 110224 100000 886.0MB/s html [ +1.5%]
|
1027
|
+
BM_UFlat/1 1036523 1036508 10000 646.0MB/s urls [ -0.8%]
|
1028
|
+
BM_UFlat/2 26775 26775 522570 4.4GB/s jpg [ +0.0%]
|
1029
|
+
BM_UFlat/3 49738 49737 280974 1.8GB/s pdf [ +0.3%]
|
1030
|
+
BM_UFlat/4 446790 446792 31334 874.3MB/s html4 [ +0.8%]
|
1031
|
+
BM_UFlat/5 40561 40562 350424 578.5MB/s cp [ +1.3%]
|
1032
|
+
BM_UFlat/6 18722 18722 746903 568.0MB/s c [ +1.4%]
|
1033
|
+
BM_UFlat/7 5373 5373 2608632 660.5MB/s lsp [ +8.3%]
|
1034
|
+
BM_UFlat/8 1615716 1615718 8670 607.8MB/s xls [ +2.0%]
|
1035
|
+
BM_UFlat/9 345278 345281 40481 420.1MB/s txt1 [ +1.4%]
|
1036
|
+
BM_UFlat/10 294855 294855 47452 404.9MB/s txt2 [ +1.6%]
|
1037
|
+
BM_UFlat/11 914263 914263 15316 445.2MB/s txt3 [ +1.1%]
|
1038
|
+
BM_UFlat/12 1222694 1222691 10000 375.8MB/s txt4 [ +1.4%]
|
1039
|
+
BM_UFlat/13 584495 584489 23954 837.4MB/s bin [ -0.6%]
|
1040
|
+
BM_UFlat/14 66662 66662 210123 547.1MB/s sum [ +1.2%]
|
1041
|
+
BM_UFlat/15 7368 7368 1881856 547.1MB/s man [ +4.0%]
|
1042
|
+
BM_UFlat/16 110727 110726 100000 1021.4MB/s pb [ +2.3%]
|
1043
|
+
BM_UFlat/17 382138 382141 36616 460.0MB/s gaviota [ -0.7%]
|
1044
|
+
|
1045
|
+
Westmere (Core i7):
|
1046
|
+
|
1047
|
+
Benchmark Time(ns) CPU(ns) Iterations
|
1048
|
+
--------------------------------------------
|
1049
|
+
BM_UFlat/0 78861 78853 177703 1.2GB/s html [ +2.1%]
|
1050
|
+
BM_UFlat/1 739560 739491 18912 905.4MB/s urls [ +3.4%]
|
1051
|
+
BM_UFlat/2 9867 9866 1419014 12.0GB/s jpg [ +3.4%]
|
1052
|
+
BM_UFlat/3 31989 31986 438385 2.7GB/s pdf [ +0.2%]
|
1053
|
+
BM_UFlat/4 319406 319380 43771 1.2GB/s html4 [ +1.9%]
|
1054
|
+
BM_UFlat/5 29639 29636 472862 791.7MB/s cp [ +5.2%]
|
1055
|
+
BM_UFlat/6 13478 13477 1000000 789.0MB/s c [ +2.3%]
|
1056
|
+
BM_UFlat/7 4030 4029 3475364 880.7MB/s lsp [ +8.7%]
|
1057
|
+
BM_UFlat/8 1036585 1036492 10000 947.5MB/s xls [ +6.9%]
|
1058
|
+
BM_UFlat/9 242127 242105 57838 599.1MB/s txt1 [ +3.0%]
|
1059
|
+
BM_UFlat/10 206499 206480 67595 578.2MB/s txt2 [ +3.4%]
|
1060
|
+
BM_UFlat/11 641635 641570 21811 634.4MB/s txt3 [ +2.4%]
|
1061
|
+
BM_UFlat/12 848847 848769 16443 541.4MB/s txt4 [ +3.1%]
|
1062
|
+
BM_UFlat/13 384968 384938 36366 1.2GB/s bin [ +0.3%]
|
1063
|
+
BM_UFlat/14 47106 47101 297770 774.3MB/s sum [ +4.4%]
|
1064
|
+
BM_UFlat/15 5063 5063 2772202 796.2MB/s man [ +7.7%]
|
1065
|
+
BM_UFlat/16 83663 83656 167697 1.3GB/s pb [ +1.8%]
|
1066
|
+
BM_UFlat/17 260224 260198 53823 675.6MB/s gaviota [ -0.5%]
|
1067
|
+
|
1068
|
+
Barcelona (Opteron):
|
1069
|
+
|
1070
|
+
Benchmark Time(ns) CPU(ns) Iterations
|
1071
|
+
--------------------------------------------
|
1072
|
+
BM_UFlat/0 112490 112457 100000 868.4MB/s html [ -0.4%]
|
1073
|
+
BM_UFlat/1 1066719 1066339 10000 627.9MB/s urls [ +1.0%]
|
1074
|
+
BM_UFlat/2 24679 24672 563802 4.8GB/s jpg [ +0.7%]
|
1075
|
+
BM_UFlat/3 50603 50589 277285 1.7GB/s pdf [ +2.6%]
|
1076
|
+
BM_UFlat/4 452982 452849 30900 862.6MB/s html4 [ -0.2%]
|
1077
|
+
BM_UFlat/5 43860 43848 319554 535.1MB/s cp [ +1.2%]
|
1078
|
+
BM_UFlat/6 21419 21413 653573 496.6MB/s c [ +1.0%]
|
1079
|
+
BM_UFlat/7 6646 6645 2105405 534.1MB/s lsp [ +0.3%]
|
1080
|
+
BM_UFlat/8 1828487 1827886 7658 537.3MB/s xls [ +2.6%]
|
1081
|
+
BM_UFlat/9 391824 391714 35708 370.3MB/s txt1 [ +2.2%]
|
1082
|
+
BM_UFlat/10 334913 334816 41885 356.6MB/s txt2 [ +1.7%]
|
1083
|
+
BM_UFlat/11 1042062 1041674 10000 390.7MB/s txt3 [ +1.1%]
|
1084
|
+
BM_UFlat/12 1398902 1398456 10000 328.6MB/s txt4 [ +1.7%]
|
1085
|
+
BM_UFlat/13 545706 545530 25669 897.2MB/s bin [ -0.4%]
|
1086
|
+
BM_UFlat/14 71512 71505 196035 510.0MB/s sum [ +1.4%]
|
1087
|
+
BM_UFlat/15 8422 8421 1665036 478.7MB/s man [ +2.6%]
|
1088
|
+
BM_UFlat/16 112053 112048 100000 1009.3MB/s pb [ -0.4%]
|
1089
|
+
BM_UFlat/17 416723 416713 33612 421.8MB/s gaviota [ -2.0%]
|
1090
|
+
|
1091
|
+
R=sanjay
|
1092
|
+
|
1093
|
+
------------------------------------------------------------------------
|
1094
|
+
r52 | snappy.mirrorbot@gmail.com | 2011-11-08 15:46:39 +0100 (Tue, 08 Nov 2011) | 5 lines
|
1095
|
+
|
1096
|
+
Fix public issue #53: Update the README to the API we actually open-sourced
|
1097
|
+
with.
|
1098
|
+
|
1099
|
+
R=sanjay
|
1100
|
+
|
1101
|
+
------------------------------------------------------------------------
|
1102
|
+
r51 | snappy.mirrorbot@gmail.com | 2011-10-05 14:27:12 +0200 (Wed, 05 Oct 2011) | 5 lines
|
1103
|
+
|
1104
|
+
In the format description, use a clearer example to emphasize that varints are
|
1105
|
+
stored in little-endian. Patch from Christian von Roques.
|
1106
|
+
|
1107
|
+
R=csilvers
|
1108
|
+
|
1109
|
+
------------------------------------------------------------------------
|
1110
|
+
r50 | snappy.mirrorbot@gmail.com | 2011-09-15 21:34:06 +0200 (Thu, 15 Sep 2011) | 4 lines
|
1111
|
+
|
1112
|
+
Release Snappy 1.0.4.
|
1113
|
+
|
1114
|
+
R=sanjay
|
1115
|
+
|
1116
|
+
------------------------------------------------------------------------
|
1117
|
+
r49 | snappy.mirrorbot@gmail.com | 2011-09-15 11:50:05 +0200 (Thu, 15 Sep 2011) | 5 lines
|
1118
|
+
|
1119
|
+
Fix public issue #50: Include generic byteswap macros.
|
1120
|
+
Also include Solaris 10 and FreeBSD versions.
|
1121
|
+
|
1122
|
+
R=csilvers
|
1123
|
+
|
1124
|
+
------------------------------------------------------------------------
|
1125
|
+
r48 | snappy.mirrorbot@gmail.com | 2011-08-10 20:57:27 +0200 (Wed, 10 Aug 2011) | 5 lines
|
1126
|
+
|
1127
|
+
Partially fix public issue 50: Remove an extra comma from the end of some
|
1128
|
+
enum declarations, as it seems the Sun compiler does not like it.
|
1129
|
+
|
1130
|
+
Based on patch by Travis Vitek.
|
1131
|
+
|
1132
|
+
------------------------------------------------------------------------
|
1133
|
+
r47 | snappy.mirrorbot@gmail.com | 2011-08-10 20:44:16 +0200 (Wed, 10 Aug 2011) | 4 lines
|
1134
|
+
|
1135
|
+
Use the right #ifdef test for sys/mman.h.
|
1136
|
+
|
1137
|
+
Based on patch by Travis Vitek.
|
1138
|
+
|
1139
|
+
------------------------------------------------------------------------
|
1140
|
+
r46 | snappy.mirrorbot@gmail.com | 2011-08-10 03:22:09 +0200 (Wed, 10 Aug 2011) | 6 lines
|
1141
|
+
|
1142
|
+
Fix public issue #47: Small comment cleanups in the unit test.
|
1143
|
+
|
1144
|
+
Originally based on a patch by Patrick Pelletier.
|
1145
|
+
|
1146
|
+
R=sanjay
|
1147
|
+
|
1148
|
+
------------------------------------------------------------------------
|
1149
|
+
r45 | snappy.mirrorbot@gmail.com | 2011-08-10 03:14:43 +0200 (Wed, 10 Aug 2011) | 8 lines
|
1150
|
+
|
1151
|
+
Fix public issue #46: Format description said "3-byte offset"
|
1152
|
+
instead of "4-byte offset" for the longest copies.
|
1153
|
+
|
1154
|
+
Also fix an inconsistency in the heading for section 2.2.3.
|
1155
|
+
Both patches by Patrick Pelletier.
|
1156
|
+
|
1157
|
+
R=csilvers
|
1158
|
+
|
1159
|
+
------------------------------------------------------------------------
|
1160
|
+
r44 | snappy.mirrorbot@gmail.com | 2011-06-28 13:40:25 +0200 (Tue, 28 Jun 2011) | 8 lines
|
1161
|
+
|
1162
|
+
Fix public issue #44: Make the definition and declaration of CompressFragment
|
1163
|
+
identical, even regarding cv-qualifiers.
|
1164
|
+
|
1165
|
+
This is required to work around a bug in the Solaris Studio C++ compiler
|
1166
|
+
(it does not properly disregard cv-qualifiers when doing name mangling).
|
1167
|
+
|
1168
|
+
R=sanjay
|
1169
|
+
|
1170
|
+
------------------------------------------------------------------------
|
1171
|
+
r43 | snappy.mirrorbot@gmail.com | 2011-06-04 12:19:05 +0200 (Sat, 04 Jun 2011) | 7 lines
|
1172
|
+
|
1173
|
+
Correct an inaccuracy in the Snappy format description.
|
1174
|
+
(I stumbled into this when changing the way we decompress literals.)
|
1175
|
+
|
1176
|
+
R=csilvers
|
1177
|
+
|
1178
|
+
Revision created by MOE tool push_codebase.
|
1179
|
+
|
1180
|
+
------------------------------------------------------------------------
|
1181
|
+
r42 | snappy.mirrorbot@gmail.com | 2011-06-03 22:53:06 +0200 (Fri, 03 Jun 2011) | 50 lines
|
1182
|
+
|
1183
|
+
Speed up decompression by removing a fast-path attempt.
|
1184
|
+
|
1185
|
+
Whenever we try to enter a copy fast-path, there is a certain cost in checking
|
1186
|
+
that all the preconditions are in place, but it's normally offset by the fact
|
1187
|
+
that we can usually take the cheaper path. However, in a certain path we've
|
1188
|
+
already established that "avail < literal_length", which usually means that
|
1189
|
+
either the available space is small, or the literal is big. Both will disqualify
|
1190
|
+
us from taking the fast path, and thus we take the hit from the precondition
|
1191
|
+
checking without gaining much from having a fast path. Thus, simply don't try
|
1192
|
+
the fast path in this situation -- we're already on a slow path anyway
|
1193
|
+
(one where we need to refill more data from the reader).
|
1194
|
+
|
1195
|
+
I'm a bit surprised at how much this gained; it could be that this path is
|
1196
|
+
more common than I thought, or that the simpler structure somehow makes the
|
1197
|
+
compiler happier. I haven't looked at the assembler, but it's a win across
|
1198
|
+
the board on both Core 2, Core i7 and Opteron, at least for the cases we
|
1199
|
+
typically care about. The gains seem to be the largest on Core i7, though.
|
1200
|
+
Results from my Core i7 workstation:
|
1201
|
+
|
1202
|
+
|
1203
|
+
Benchmark Time(ns) CPU(ns) Iterations
|
1204
|
+
---------------------------------------------------
|
1205
|
+
BM_UFlat/0 73337 73091 190996 1.3GB/s html [ +1.7%]
|
1206
|
+
BM_UFlat/1 696379 693501 20173 965.5MB/s urls [ +2.7%]
|
1207
|
+
BM_UFlat/2 9765 9734 1472135 12.1GB/s jpg [ +0.7%]
|
1208
|
+
BM_UFlat/3 29720 29621 472973 3.0GB/s pdf [ +1.8%]
|
1209
|
+
BM_UFlat/4 294636 293834 47782 1.3GB/s html4 [ +2.3%]
|
1210
|
+
BM_UFlat/5 28399 28320 494700 828.5MB/s cp [ +3.5%]
|
1211
|
+
BM_UFlat/6 12795 12760 1000000 833.3MB/s c [ +1.2%]
|
1212
|
+
BM_UFlat/7 3984 3973 3526448 893.2MB/s lsp [ +5.7%]
|
1213
|
+
BM_UFlat/8 991996 989322 14141 992.6MB/s xls [ +3.3%]
|
1214
|
+
BM_UFlat/9 228620 227835 61404 636.6MB/s txt1 [ +4.0%]
|
1215
|
+
BM_UFlat/10 197114 196494 72165 607.5MB/s txt2 [ +3.5%]
|
1216
|
+
BM_UFlat/11 605240 603437 23217 674.4MB/s txt3 [ +3.7%]
|
1217
|
+
BM_UFlat/12 804157 802016 17456 573.0MB/s txt4 [ +3.9%]
|
1218
|
+
BM_UFlat/13 347860 346998 40346 1.4GB/s bin [ +1.2%]
|
1219
|
+
BM_UFlat/14 44684 44559 315315 818.4MB/s sum [ +2.3%]
|
1220
|
+
BM_UFlat/15 5120 5106 2739726 789.4MB/s man [ +3.3%]
|
1221
|
+
BM_UFlat/16 76591 76355 183486 1.4GB/s pb [ +2.8%]
|
1222
|
+
BM_UFlat/17 238564 237828 58824 739.1MB/s gaviota [ +1.6%]
|
1223
|
+
BM_UValidate/0 42194 42060 333333 2.3GB/s html [ -0.1%]
|
1224
|
+
BM_UValidate/1 433182 432005 32407 1.5GB/s urls [ -0.1%]
|
1225
|
+
BM_UValidate/2 197 196 71428571 603.3GB/s jpg [ +0.5%]
|
1226
|
+
BM_UValidate/3 14494 14462 972222 6.1GB/s pdf [ +0.5%]
|
1227
|
+
BM_UValidate/4 168444 167836 83832 2.3GB/s html4 [ +0.1%]
|
1228
|
+
|
1229
|
+
R=jeff
|
1230
|
+
|
1231
|
+
Revision created by MOE tool push_codebase.
|
1232
|
+
|
1233
|
+
------------------------------------------------------------------------
|
1234
|
+
r41 | snappy.mirrorbot@gmail.com | 2011-06-03 22:47:14 +0200 (Fri, 03 Jun 2011) | 43 lines
|
1235
|
+
|
1236
|
+
Speed up decompression by not needing a lookup table for literal items.
|
1237
|
+
|
1238
|
+
Looking up into and decoding the values from char_table has long shown up as a
|
1239
|
+
hotspot in the decompressor. While it turns out that it's hard to make a more
|
1240
|
+
efficient decoder for the copy ops, the literals are simple enough that we can
|
1241
|
+
decode them without needing a table lookup. (This means that 1/4 of the table
|
1242
|
+
is now unused, although that in itself doesn't buy us anything.)
|
1243
|
+
|
1244
|
+
The gains are small, but definitely present; some tests win as much as 10%,
|
1245
|
+
but 1-4% is more typical. These results are from Core i7, in 64-bit mode;
|
1246
|
+
Core 2 and Opteron show similar results. (I've run with more iterations
|
1247
|
+
than unusual to make sure the smaller gains don't drown entirely in noise.)
|
1248
|
+
|
1249
|
+
Benchmark Time(ns) CPU(ns) Iterations
|
1250
|
+
---------------------------------------------------
|
1251
|
+
BM_UFlat/0 74665 74428 182055 1.3GB/s html [ +3.1%]
|
1252
|
+
BM_UFlat/1 714106 711997 19663 940.4MB/s urls [ +4.4%]
|
1253
|
+
BM_UFlat/2 9820 9789 1427115 12.1GB/s jpg [ -1.2%]
|
1254
|
+
BM_UFlat/3 30461 30380 465116 2.9GB/s pdf [ +0.8%]
|
1255
|
+
BM_UFlat/4 301445 300568 46512 1.3GB/s html4 [ +2.2%]
|
1256
|
+
BM_UFlat/5 29338 29263 479452 801.8MB/s cp [ +1.6%]
|
1257
|
+
BM_UFlat/6 13004 12970 1000000 819.9MB/s c [ +2.1%]
|
1258
|
+
BM_UFlat/7 4180 4168 3349282 851.4MB/s lsp [ +1.3%]
|
1259
|
+
BM_UFlat/8 1026149 1024000 10000 959.0MB/s xls [+10.7%]
|
1260
|
+
BM_UFlat/9 237441 236830 59072 612.4MB/s txt1 [ +0.3%]
|
1261
|
+
BM_UFlat/10 203966 203298 69307 587.2MB/s txt2 [ +0.8%]
|
1262
|
+
BM_UFlat/11 627230 625000 22400 651.2MB/s txt3 [ +0.7%]
|
1263
|
+
BM_UFlat/12 836188 833979 16787 551.0MB/s txt4 [ +1.3%]
|
1264
|
+
BM_UFlat/13 351904 350750 39886 1.4GB/s bin [ +3.8%]
|
1265
|
+
BM_UFlat/14 45685 45562 308370 800.4MB/s sum [ +5.9%]
|
1266
|
+
BM_UFlat/15 5286 5270 2656546 764.9MB/s man [ +1.5%]
|
1267
|
+
BM_UFlat/16 78774 78544 178117 1.4GB/s pb [ +4.3%]
|
1268
|
+
BM_UFlat/17 242270 241345 58091 728.3MB/s gaviota [ +1.2%]
|
1269
|
+
BM_UValidate/0 42149 42000 333333 2.3GB/s html [ -3.0%]
|
1270
|
+
BM_UValidate/1 432741 431303 32483 1.5GB/s urls [ +7.8%]
|
1271
|
+
BM_UValidate/2 198 197 71428571 600.7GB/s jpg [+16.8%]
|
1272
|
+
BM_UValidate/3 14560 14521 965517 6.1GB/s pdf [ -4.1%]
|
1273
|
+
BM_UValidate/4 169065 168671 83832 2.3GB/s html4 [ -2.9%]
|
1274
|
+
|
1275
|
+
R=jeff
|
1276
|
+
|
1277
|
+
Revision created by MOE tool push_codebase.
|
1278
|
+
|
1279
|
+
------------------------------------------------------------------------
|
1280
|
+
r40 | snappy.mirrorbot@gmail.com | 2011-06-03 00:57:41 +0200 (Fri, 03 Jun 2011) | 2 lines
|
1281
|
+
|
1282
|
+
Release Snappy 1.0.3.
|
1283
|
+
|
1284
|
+
------------------------------------------------------------------------
|
1285
|
+
r39 | snappy.mirrorbot@gmail.com | 2011-06-02 20:06:54 +0200 (Thu, 02 Jun 2011) | 11 lines
|
1286
|
+
|
1287
|
+
Remove an unneeded goto in the decompressor; it turns out that the
|
1288
|
+
state of ip_ after decompression (or attempted decompresion) is
|
1289
|
+
completely irrelevant, so we don't need the trailer.
|
1290
|
+
|
1291
|
+
Performance is, as expected, mostly flat -- there's a curious ~3-5%
|
1292
|
+
loss in the "lsp" test, but that test case is so short it is hard to say
|
1293
|
+
anything definitive about why (most likely, it's some sort of
|
1294
|
+
unrelated effect).
|
1295
|
+
|
1296
|
+
R=jeff
|
1297
|
+
|
1298
|
+
------------------------------------------------------------------------
|
1299
|
+
r38 | snappy.mirrorbot@gmail.com | 2011-06-02 19:59:40 +0200 (Thu, 02 Jun 2011) | 52 lines
|
1300
|
+
|
1301
|
+
Speed up decompression by caching ip_.
|
1302
|
+
|
1303
|
+
It is seemingly hard for the compiler to understand that ip_, the current input
|
1304
|
+
pointer into the compressed data stream, can not alias on anything else, and
|
1305
|
+
thus using it directly will incur memory traffic as it cannot be kept in a
|
1306
|
+
register. The code already knew about this and cached it into a local
|
1307
|
+
variable, but since Step() only decoded one tag, it had to move ip_ back into
|
1308
|
+
place between every tag. This seems to have cost us a significant amount of
|
1309
|
+
performance, so changing Step() into a function that decodes as much as it can
|
1310
|
+
before it saves ip_ back and returns. (Note that Step() was already inlined,
|
1311
|
+
so it is not the manual inlining that buys the performance here.)
|
1312
|
+
|
1313
|
+
The wins are about 3-6% for Core 2, 6-13% on Core i7 and 5-12% on Opteron
|
1314
|
+
(for plain array-to-array decompression, in 64-bit opt mode).
|
1315
|
+
|
1316
|
+
There is a tiny difference in the behavior here; if an invalid literal is
|
1317
|
+
encountered (ie., the writer refuses the Append() operation), ip_ will now
|
1318
|
+
point to the byte past the tag byte, instead of where the literal was
|
1319
|
+
originally thought to end. However, we don't use ip_ for anything after
|
1320
|
+
DecompressAllTags() has returned, so this should not change external behavior
|
1321
|
+
in any way.
|
1322
|
+
|
1323
|
+
Microbenchmark results for Core i7, 64-bit (Opteron results are similar):
|
1324
|
+
|
1325
|
+
Benchmark Time(ns) CPU(ns) Iterations
|
1326
|
+
---------------------------------------------------
|
1327
|
+
BM_UFlat/0 79134 79110 8835 1.2GB/s html [ +6.2%]
|
1328
|
+
BM_UFlat/1 786126 786096 891 851.8MB/s urls [+10.0%]
|
1329
|
+
BM_UFlat/2 9948 9948 69125 11.9GB/s jpg [ -1.3%]
|
1330
|
+
BM_UFlat/3 31999 31998 21898 2.7GB/s pdf [ +6.5%]
|
1331
|
+
BM_UFlat/4 318909 318829 2204 1.2GB/s html4 [ +6.5%]
|
1332
|
+
BM_UFlat/5 31384 31390 22363 747.5MB/s cp [ +9.2%]
|
1333
|
+
BM_UFlat/6 14037 14034 49858 757.7MB/s c [+10.6%]
|
1334
|
+
BM_UFlat/7 4612 4612 151395 769.5MB/s lsp [ +9.5%]
|
1335
|
+
BM_UFlat/8 1203174 1203007 582 816.3MB/s xls [+19.3%]
|
1336
|
+
BM_UFlat/9 253869 253955 2757 571.1MB/s txt1 [+11.4%]
|
1337
|
+
BM_UFlat/10 219292 219290 3194 544.4MB/s txt2 [+12.1%]
|
1338
|
+
BM_UFlat/11 672135 672131 1000 605.5MB/s txt3 [+11.2%]
|
1339
|
+
BM_UFlat/12 902512 902492 776 509.2MB/s txt4 [+12.5%]
|
1340
|
+
BM_UFlat/13 372110 371998 1881 1.3GB/s bin [ +5.8%]
|
1341
|
+
BM_UFlat/14 50407 50407 10000 723.5MB/s sum [+13.5%]
|
1342
|
+
BM_UFlat/15 5699 5701 100000 707.2MB/s man [+12.4%]
|
1343
|
+
BM_UFlat/16 83448 83424 8383 1.3GB/s pb [ +5.7%]
|
1344
|
+
BM_UFlat/17 256958 256963 2723 684.1MB/s gaviota [ +7.9%]
|
1345
|
+
BM_UValidate/0 42795 42796 16351 2.2GB/s html [+25.8%]
|
1346
|
+
BM_UValidate/1 490672 490622 1427 1.3GB/s urls [+22.7%]
|
1347
|
+
BM_UValidate/2 237 237 2950297 499.0GB/s jpg [+24.9%]
|
1348
|
+
BM_UValidate/3 14610 14611 47901 6.0GB/s pdf [+26.8%]
|
1349
|
+
BM_UValidate/4 171973 171990 4071 2.2GB/s html4 [+25.7%]
|
1350
|
+
|
1351
|
+
|
1352
|
+
|
1353
|
+
------------------------------------------------------------------------
|
1354
|
+
r37 | snappy.mirrorbot@gmail.com | 2011-05-17 10:48:25 +0200 (Tue, 17 May 2011) | 10 lines
|
1355
|
+
|
1356
|
+
|
1357
|
+
Fix the numbering of the headlines in the Snappy format description.
|
1358
|
+
|
1359
|
+
R=csilvers
|
1360
|
+
DELTA=4 (0 added, 0 deleted, 4 changed)
|
1361
|
+
|
1362
|
+
|
1363
|
+
Revision created by MOE tool push_codebase.
|
1364
|
+
MOE_MIGRATION=1906
|
1365
|
+
|
1366
|
+
------------------------------------------------------------------------
|
1367
|
+
r36 | snappy.mirrorbot@gmail.com | 2011-05-16 10:59:18 +0200 (Mon, 16 May 2011) | 12 lines
|
1368
|
+
|
1369
|
+
|
1370
|
+
Fix public issue #32: Add compressed format documentation for Snappy.
|
1371
|
+
This text is new, but an earlier version from Zeev Tarantov was used
|
1372
|
+
as reference.
|
1373
|
+
|
1374
|
+
R=csilvers
|
1375
|
+
DELTA=112 (111 added, 0 deleted, 1 changed)
|
1376
|
+
|
1377
|
+
|
1378
|
+
Revision created by MOE tool push_codebase.
|
1379
|
+
MOE_MIGRATION=1867
|
1380
|
+
|
1381
|
+
------------------------------------------------------------------------
|
1382
|
+
r35 | snappy.mirrorbot@gmail.com | 2011-05-09 23:29:02 +0200 (Mon, 09 May 2011) | 12 lines
|
1383
|
+
|
1384
|
+
|
1385
|
+
Fix public issue #39: Pick out the median runs based on CPU time,
|
1386
|
+
not real time. Also, use nth_element instead of sort, since we
|
1387
|
+
only need one element.
|
1388
|
+
|
1389
|
+
R=csilvers
|
1390
|
+
DELTA=5 (3 added, 0 deleted, 2 changed)
|
1391
|
+
|
1392
|
+
|
1393
|
+
Revision created by MOE tool push_codebase.
|
1394
|
+
MOE_MIGRATION=1799
|
1395
|
+
|
1396
|
+
------------------------------------------------------------------------
|
1397
|
+
r34 | snappy.mirrorbot@gmail.com | 2011-05-09 23:28:45 +0200 (Mon, 09 May 2011) | 19 lines
|
1398
|
+
|
1399
|
+
|
1400
|
+
Fix public issue #38: Make the microbenchmark framework handle
|
1401
|
+
properly cases where gettimeofday() can stand return the same
|
1402
|
+
result twice (as sometimes on GNU/Hurd) or go backwards
|
1403
|
+
(as when the user adjusts the clock). We avoid a division-by-zero,
|
1404
|
+
and put a lower bound on the number of iterations -- the same
|
1405
|
+
amount as we use to calibrate.
|
1406
|
+
|
1407
|
+
We should probably use CLOCK_MONOTONIC for platforms that support
|
1408
|
+
it, to be robust against clock adjustments; we already use Windows'
|
1409
|
+
monotonic timers. However, that's for a later changelist.
|
1410
|
+
|
1411
|
+
R=csilvers
|
1412
|
+
DELTA=7 (5 added, 0 deleted, 2 changed)
|
1413
|
+
|
1414
|
+
|
1415
|
+
Revision created by MOE tool push_codebase.
|
1416
|
+
MOE_MIGRATION=1798
|
1417
|
+
|
1418
|
+
------------------------------------------------------------------------
|
1419
|
+
r33 | snappy.mirrorbot@gmail.com | 2011-05-04 01:22:52 +0200 (Wed, 04 May 2011) | 11 lines
|
1420
|
+
|
1421
|
+
|
1422
|
+
Fix public issue #37: Only link snappy_unittest against -lz and other autodetected
|
1423
|
+
libraries, not libsnappy.so (which doesn't need any such dependency).
|
1424
|
+
|
1425
|
+
R=csilvers
|
1426
|
+
DELTA=20 (14 added, 0 deleted, 6 changed)
|
1427
|
+
|
1428
|
+
|
1429
|
+
Revision created by MOE tool push_codebase.
|
1430
|
+
MOE_MIGRATION=1710
|
1431
|
+
|
1432
|
+
------------------------------------------------------------------------
|
1433
|
+
r32 | snappy.mirrorbot@gmail.com | 2011-05-04 01:22:33 +0200 (Wed, 04 May 2011) | 11 lines
|
1434
|
+
|
1435
|
+
|
1436
|
+
Release Snappy 1.0.2, to get the license change and various other fixes into
|
1437
|
+
a release.
|
1438
|
+
|
1439
|
+
R=csilvers
|
1440
|
+
DELTA=239 (236 added, 0 deleted, 3 changed)
|
1441
|
+
|
1442
|
+
|
1443
|
+
Revision created by MOE tool push_codebase.
|
1444
|
+
MOE_MIGRATION=1709
|
1445
|
+
|
1446
|
+
------------------------------------------------------------------------
|
1447
|
+
r31 | snappy.mirrorbot@gmail.com | 2011-04-26 14:34:55 +0200 (Tue, 26 Apr 2011) | 15 lines
|
1448
|
+
|
1449
|
+
|
1450
|
+
Fix public issue #30: Stop using gettimeofday() altogether on Win32,
|
1451
|
+
as MSVC doesn't include it. Replace with QueryPerformanceCounter(),
|
1452
|
+
which is monotonic and probably reasonably high-resolution.
|
1453
|
+
(Some machines have traditionally had bugs in QPC, but they should
|
1454
|
+
be relatively rare these days, and there's really no much better
|
1455
|
+
alternative that I know of.)
|
1456
|
+
|
1457
|
+
R=csilvers
|
1458
|
+
DELTA=74 (55 added, 19 deleted, 0 changed)
|
1459
|
+
|
1460
|
+
|
1461
|
+
Revision created by MOE tool push_codebase.
|
1462
|
+
MOE_MIGRATION=1556
|
1463
|
+
|
1464
|
+
------------------------------------------------------------------------
|
1465
|
+
r30 | snappy.mirrorbot@gmail.com | 2011-04-26 14:34:37 +0200 (Tue, 26 Apr 2011) | 11 lines
|
1466
|
+
|
1467
|
+
|
1468
|
+
Fix public issue #31: Don't reset PATH in autogen.sh; instead, do the trickery
|
1469
|
+
we need for our own build system internally.
|
1470
|
+
|
1471
|
+
R=csilvers
|
1472
|
+
DELTA=16 (13 added, 1 deleted, 2 changed)
|
1473
|
+
|
1474
|
+
|
1475
|
+
Revision created by MOE tool push_codebase.
|
1476
|
+
MOE_MIGRATION=1555
|
1477
|
+
|
1478
|
+
------------------------------------------------------------------------
|
1479
|
+
r29 | snappy.mirrorbot@gmail.com | 2011-04-16 00:55:56 +0200 (Sat, 16 Apr 2011) | 12 lines
|
1480
|
+
|
1481
|
+
|
1482
|
+
When including <windows.h>, define WIN32_LEAN_AND_MEAN first,
|
1483
|
+
so we won't pull in macro definitions of things like min() and max(),
|
1484
|
+
which can conflict with <algorithm>.
|
1485
|
+
|
1486
|
+
R=csilvers
|
1487
|
+
DELTA=1 (1 added, 0 deleted, 0 changed)
|
1488
|
+
|
1489
|
+
|
1490
|
+
Revision created by MOE tool push_codebase.
|
1491
|
+
MOE_MIGRATION=1485
|
1492
|
+
|
1493
|
+
------------------------------------------------------------------------
|
1494
|
+
r28 | snappy.mirrorbot@gmail.com | 2011-04-11 11:07:01 +0200 (Mon, 11 Apr 2011) | 15 lines
|
1495
|
+
|
1496
|
+
|
1497
|
+
Fix public issue #29: Write CPU timing code for Windows, based on GetProcessTimes()
|
1498
|
+
instead of getursage().
|
1499
|
+
|
1500
|
+
I thought I'd already committed this patch, so that the 1.0.1 release already
|
1501
|
+
would have a Windows-compatible snappy_unittest, but I'd seemingly deleted it
|
1502
|
+
instead, so this is a reconstruction.
|
1503
|
+
|
1504
|
+
R=csilvers
|
1505
|
+
DELTA=43 (39 added, 3 deleted, 1 changed)
|
1506
|
+
|
1507
|
+
|
1508
|
+
Revision created by MOE tool push_codebase.
|
1509
|
+
MOE_MIGRATION=1295
|
1510
|
+
|
1511
|
+
------------------------------------------------------------------------
|
1512
|
+
r27 | snappy.mirrorbot@gmail.com | 2011-04-08 11:51:53 +0200 (Fri, 08 Apr 2011) | 22 lines
|
1513
|
+
|
1514
|
+
|
1515
|
+
Include C bindings of Snappy, contributed by Martin Gieseking.
|
1516
|
+
|
1517
|
+
I've made a few changes since Martin's version; mostly style nits, but also
|
1518
|
+
a semantic change -- most functions that return bool in the C++ version now
|
1519
|
+
return an enum, to better match typical C (and zlib) semantics.
|
1520
|
+
|
1521
|
+
I've kept the copyright notice, since Martin is obviously the author here;
|
1522
|
+
he has signed the contributor license agreement, though, so this should not
|
1523
|
+
hinder Google's use in the future.
|
1524
|
+
|
1525
|
+
We'll need to update the libtool version number to match the added interface,
|
1526
|
+
but as of http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
|
1527
|
+
I'm going to wait until public release.
|
1528
|
+
|
1529
|
+
R=csilvers
|
1530
|
+
DELTA=238 (233 added, 0 deleted, 5 changed)
|
1531
|
+
|
1532
|
+
|
1533
|
+
Revision created by MOE tool push_codebase.
|
1534
|
+
MOE_MIGRATION=1294
|
1535
|
+
|
1536
|
+
------------------------------------------------------------------------
|
1537
|
+
r26 | snappy.mirrorbot@gmail.com | 2011-04-07 18:36:43 +0200 (Thu, 07 Apr 2011) | 13 lines
|
1538
|
+
|
1539
|
+
|
1540
|
+
Replace geo.protodata with a newer version.
|
1541
|
+
|
1542
|
+
The data compresses/decompresses slightly faster than the old data, and has
|
1543
|
+
similar density.
|
1544
|
+
|
1545
|
+
R=lookingbill
|
1546
|
+
DELTA=1 (0 added, 0 deleted, 1 changed)
|
1547
|
+
|
1548
|
+
|
1549
|
+
Revision created by MOE tool push_codebase.
|
1550
|
+
MOE_MIGRATION=1288
|
1551
|
+
|
1552
|
+
------------------------------------------------------------------------
|
1553
|
+
r25 | snappy.mirrorbot@gmail.com | 2011-03-30 22:27:53 +0200 (Wed, 30 Mar 2011) | 12 lines
|
1554
|
+
|
1555
|
+
|
1556
|
+
Fix public issue #27: Add HAVE_CONFIG_H tests around the config.h
|
1557
|
+
inclusion in snappy-stubs-internal.h, which eases compiling outside the
|
1558
|
+
automake/autoconf framework.
|
1559
|
+
|
1560
|
+
R=csilvers
|
1561
|
+
DELTA=5 (4 added, 1 deleted, 0 changed)
|
1562
|
+
|
1563
|
+
|
1564
|
+
Revision created by MOE tool push_codebase.
|
1565
|
+
MOE_MIGRATION=1152
|
1566
|
+
|
1567
|
+
------------------------------------------------------------------------
|
1568
|
+
r24 | snappy.mirrorbot@gmail.com | 2011-03-30 22:27:39 +0200 (Wed, 30 Mar 2011) | 13 lines
|
1569
|
+
|
1570
|
+
|
1571
|
+
Fix public issue #26: Take memory allocation and reallocation entirely out of the
|
1572
|
+
Measure() loop. This gives all algorithms a small speed boost, except Snappy which
|
1573
|
+
already didn't do reallocation (so the measurements were slightly biased in its
|
1574
|
+
favor).
|
1575
|
+
|
1576
|
+
R=csilvers
|
1577
|
+
DELTA=92 (69 added, 9 deleted, 14 changed)
|
1578
|
+
|
1579
|
+
|
1580
|
+
Revision created by MOE tool push_codebase.
|
1581
|
+
MOE_MIGRATION=1151
|
1582
|
+
|
1583
|
+
------------------------------------------------------------------------
|
1584
|
+
r23 | snappy.mirrorbot@gmail.com | 2011-03-30 22:25:09 +0200 (Wed, 30 Mar 2011) | 18 lines
|
1585
|
+
|
1586
|
+
|
1587
|
+
Renamed "namespace zippy" to "namespace snappy" to reduce
|
1588
|
+
the differences from the opensource code. Will make it easier
|
1589
|
+
in the future to mix-and-match third-party code that uses
|
1590
|
+
snappy with google code.
|
1591
|
+
|
1592
|
+
Currently, csearch shows that the only external user of
|
1593
|
+
"namespace zippy" is some bigtable code that accesses
|
1594
|
+
a TEST variable, which is temporarily kept in the zippy
|
1595
|
+
namespace.
|
1596
|
+
|
1597
|
+
R=sesse
|
1598
|
+
DELTA=123 (18 added, 3 deleted, 102 changed)
|
1599
|
+
|
1600
|
+
|
1601
|
+
Revision created by MOE tool push_codebase.
|
1602
|
+
MOE_MIGRATION=1150
|
1603
|
+
|
1604
|
+
------------------------------------------------------------------------
|
1605
|
+
r22 | snappy.mirrorbot@gmail.com | 2011-03-29 00:17:04 +0200 (Tue, 29 Mar 2011) | 11 lines
|
1606
|
+
|
1607
|
+
|
1608
|
+
Put back the final few lines of what was truncated during the
|
1609
|
+
license header change.
|
1610
|
+
|
1611
|
+
R=csilvers
|
1612
|
+
DELTA=5 (4 added, 0 deleted, 1 changed)
|
1613
|
+
|
1614
|
+
|
1615
|
+
Revision created by MOE tool push_codebase.
|
1616
|
+
MOE_MIGRATION=1094
|
1617
|
+
|
1618
|
+
------------------------------------------------------------------------
|
1619
|
+
r21 | snappy.mirrorbot@gmail.com | 2011-03-26 03:34:34 +0100 (Sat, 26 Mar 2011) | 20 lines
|
1620
|
+
|
1621
|
+
|
1622
|
+
Change on 2011-03-25 19:18:00-07:00 by sesse
|
1623
|
+
|
1624
|
+
Replace the Apache 2.0 license header by the BSD-type license header;
|
1625
|
+
somehow a lot of the files were missed in the last round.
|
1626
|
+
|
1627
|
+
R=dannyb,csilvers
|
1628
|
+
DELTA=147 (74 added, 2 deleted, 71 changed)
|
1629
|
+
|
1630
|
+
Change on 2011-03-25 19:25:07-07:00 by sesse
|
1631
|
+
|
1632
|
+
Unbreak the build; the relicensing removed a bit too much (only comments
|
1633
|
+
were intended, but I also accidentially removed some of the top lines of
|
1634
|
+
the actual source).
|
1635
|
+
|
1636
|
+
|
1637
|
+
|
1638
|
+
Revision created by MOE tool push_codebase.
|
1639
|
+
MOE_MIGRATION=1072
|
1640
|
+
|
1641
|
+
------------------------------------------------------------------------
|
1642
|
+
r20 | snappy.mirrorbot@gmail.com | 2011-03-25 17:14:41 +0100 (Fri, 25 Mar 2011) | 10 lines
|
1643
|
+
|
1644
|
+
|
1645
|
+
Change Snappy from the Apache 2.0 to a BSD-type license.
|
1646
|
+
|
1647
|
+
R=dannyb
|
1648
|
+
DELTA=328 (80 added, 184 deleted, 64 changed)
|
1649
|
+
|
1650
|
+
|
1651
|
+
Revision created by MOE tool push_codebase.
|
1652
|
+
MOE_MIGRATION=1061
|
1653
|
+
|
1654
|
+
------------------------------------------------------------------------
|
1655
|
+
r19 | snappy.mirrorbot@gmail.com | 2011-03-25 01:39:01 +0100 (Fri, 25 Mar 2011) | 11 lines
|
1656
|
+
|
1657
|
+
|
1658
|
+
Release Snappy 1.0.1, to soup up all the various small changes
|
1659
|
+
that have been made since release.
|
1660
|
+
|
1661
|
+
R=csilvers
|
1662
|
+
DELTA=266 (260 added, 0 deleted, 6 changed)
|
1663
|
+
|
1664
|
+
|
1665
|
+
Revision created by MOE tool push_codebase.
|
1666
|
+
MOE_MIGRATION=1057
|
1667
|
+
|
1668
|
+
------------------------------------------------------------------------
|
1669
|
+
r18 | snappy.mirrorbot@gmail.com | 2011-03-24 20:15:54 +0100 (Thu, 24 Mar 2011) | 11 lines
|
1670
|
+
|
1671
|
+
|
1672
|
+
Fix a microbenchmark crash on mingw32; seemingly %lld is not universally
|
1673
|
+
supported on Windows, and %I64d is recommended instead.
|
1674
|
+
|
1675
|
+
R=csilvers
|
1676
|
+
DELTA=6 (5 added, 0 deleted, 1 changed)
|
1677
|
+
|
1678
|
+
|
1679
|
+
Revision created by MOE tool push_codebase.
|
1680
|
+
MOE_MIGRATION=1034
|
1681
|
+
|
1682
|
+
------------------------------------------------------------------------
|
1683
|
+
r17 | snappy.mirrorbot@gmail.com | 2011-03-24 20:15:27 +0100 (Thu, 24 Mar 2011) | 13 lines
|
1684
|
+
|
1685
|
+
|
1686
|
+
Fix public issue #19: Fix unit test when Google Test is installed but the
|
1687
|
+
gflags package isn't (Google Test is not properly initialized).
|
1688
|
+
|
1689
|
+
Patch by Martin Gieseking.
|
1690
|
+
|
1691
|
+
R=csilvers
|
1692
|
+
DELTA=2 (1 added, 0 deleted, 1 changed)
|
1693
|
+
|
1694
|
+
|
1695
|
+
Revision created by MOE tool push_codebase.
|
1696
|
+
MOE_MIGRATION=1033
|
1697
|
+
|
1698
|
+
------------------------------------------------------------------------
|
1699
|
+
r16 | snappy.mirrorbot@gmail.com | 2011-03-24 20:13:57 +0100 (Thu, 24 Mar 2011) | 15 lines
|
1700
|
+
|
1701
|
+
|
1702
|
+
Make the unit test work on systems without mmap(). This is required for,
|
1703
|
+
among others, Windows support. For Windows in specific, we could have used
|
1704
|
+
CreateFileMapping/MapViewOfFile, but this should at least get us a bit closer
|
1705
|
+
to compiling, and is of course also relevant for embedded systems with no MMU.
|
1706
|
+
|
1707
|
+
(Part 2/2)
|
1708
|
+
|
1709
|
+
R=csilvers
|
1710
|
+
DELTA=15 (12 added, 3 deleted, 0 changed)
|
1711
|
+
|
1712
|
+
|
1713
|
+
Revision created by MOE tool push_codebase.
|
1714
|
+
MOE_MIGRATION=1032
|
1715
|
+
|
1716
|
+
------------------------------------------------------------------------
|
1717
|
+
r15 | snappy.mirrorbot@gmail.com | 2011-03-24 20:12:27 +0100 (Thu, 24 Mar 2011) | 15 lines
|
1718
|
+
|
1719
|
+
|
1720
|
+
Make the unit test work on systems without mmap(). This is required for,
|
1721
|
+
among others, Windows support. For Windows in specific, we could have used
|
1722
|
+
CreateFileMapping/MapViewOfFile, but this should at least get us a bit closer
|
1723
|
+
to compiling, and is of course also relevant for embedded systems with no MMU.
|
1724
|
+
|
1725
|
+
(Part 1/2)
|
1726
|
+
|
1727
|
+
R=csilvers
|
1728
|
+
DELTA=9 (8 added, 0 deleted, 1 changed)
|
1729
|
+
|
1730
|
+
|
1731
|
+
Revision created by MOE tool push_codebase.
|
1732
|
+
MOE_MIGRATION=1031
|
1733
|
+
|
1734
|
+
------------------------------------------------------------------------
|
1735
|
+
r14 | snappy.mirrorbot@gmail.com | 2011-03-24 00:17:36 +0100 (Thu, 24 Mar 2011) | 14 lines
|
1736
|
+
|
1737
|
+
|
1738
|
+
Fix public issue #12: Don't keep autogenerated auto* files in Subversion;
|
1739
|
+
it causes problems with others sending patches etc..
|
1740
|
+
|
1741
|
+
We can't get this 100% hermetic anyhow, due to files like lt~obsolete.m4,
|
1742
|
+
so we can just as well go cleanly in the other direction.
|
1743
|
+
|
1744
|
+
R=csilvers
|
1745
|
+
DELTA=21038 (0 added, 21036 deleted, 2 changed)
|
1746
|
+
|
1747
|
+
|
1748
|
+
Revision created by MOE tool push_codebase.
|
1749
|
+
MOE_MIGRATION=1012
|
1750
|
+
|
1751
|
+
------------------------------------------------------------------------
|
1752
|
+
r13 | snappy.mirrorbot@gmail.com | 2011-03-23 18:50:49 +0100 (Wed, 23 Mar 2011) | 11 lines
|
1753
|
+
|
1754
|
+
|
1755
|
+
Fix public issue tracker bug #3: Call AC_SUBST([LIBTOOL_DEPS]), or the rule
|
1756
|
+
to rebuild libtool in Makefile.am won't work.
|
1757
|
+
|
1758
|
+
R=csilvers
|
1759
|
+
DELTA=1 (1 added, 0 deleted, 0 changed)
|
1760
|
+
|
1761
|
+
|
1762
|
+
Revision created by MOE tool push_codebase.
|
1763
|
+
MOE_MIGRATION=997
|
1764
|
+
|
1765
|
+
------------------------------------------------------------------------
|
1766
|
+
r12 | snappy.mirrorbot@gmail.com | 2011-03-23 12:16:39 +0100 (Wed, 23 Mar 2011) | 11 lines
|
1767
|
+
|
1768
|
+
|
1769
|
+
Fix public issue #10: Don't add GTEST_CPPFLAGS to snappy_unittest_CXXFLAGS;
|
1770
|
+
it's not needed (CPPFLAGS are always included when compiling).
|
1771
|
+
|
1772
|
+
R=csilvers
|
1773
|
+
DELTA=1 (0 added, 1 deleted, 0 changed)
|
1774
|
+
|
1775
|
+
|
1776
|
+
Revision created by MOE tool push_codebase.
|
1777
|
+
MOE_MIGRATION=994
|
1778
|
+
|
1779
|
+
------------------------------------------------------------------------
|
1780
|
+
r11 | snappy.mirrorbot@gmail.com | 2011-03-23 12:16:18 +0100 (Wed, 23 Mar 2011) | 11 lines
|
1781
|
+
|
1782
|
+
|
1783
|
+
Fix public issue #9: Add -Wall -Werror to automake flags.
|
1784
|
+
(This concerns automake itself, not the C++ compiler.)
|
1785
|
+
|
1786
|
+
R=csilvers
|
1787
|
+
DELTA=4 (3 added, 0 deleted, 1 changed)
|
1788
|
+
|
1789
|
+
|
1790
|
+
Revision created by MOE tool push_codebase.
|
1791
|
+
MOE_MIGRATION=993
|
1792
|
+
|
1793
|
+
------------------------------------------------------------------------
|
1794
|
+
r10 | snappy.mirrorbot@gmail.com | 2011-03-23 12:13:37 +0100 (Wed, 23 Mar 2011) | 10 lines
|
1795
|
+
|
1796
|
+
|
1797
|
+
Fix a typo in the Snappy README file.
|
1798
|
+
|
1799
|
+
R=csilvers
|
1800
|
+
DELTA=1 (0 added, 0 deleted, 1 changed)
|
1801
|
+
|
1802
|
+
|
1803
|
+
Revision created by MOE tool push_codebase.
|
1804
|
+
MOE_MIGRATION=992
|
1805
|
+
|
1806
|
+
------------------------------------------------------------------------
|
1807
|
+
r9 | snappy.mirrorbot@gmail.com | 2011-03-23 12:13:13 +0100 (Wed, 23 Mar 2011) | 11 lines
|
1808
|
+
|
1809
|
+
|
1810
|
+
Fix public issue #6: Add a --with-gflags for disabling gflags autodetection
|
1811
|
+
and using a manually given setting (use/don't use) instead.
|
1812
|
+
|
1813
|
+
R=csilvers
|
1814
|
+
DELTA=16 (13 added, 0 deleted, 3 changed)
|
1815
|
+
|
1816
|
+
|
1817
|
+
Revision created by MOE tool push_codebase.
|
1818
|
+
MOE_MIGRATION=991
|
1819
|
+
|
1820
|
+
------------------------------------------------------------------------
|
1821
|
+
r8 | snappy.mirrorbot@gmail.com | 2011-03-23 12:12:44 +0100 (Wed, 23 Mar 2011) | 12 lines
|
1822
|
+
|
1823
|
+
|
1824
|
+
Fix public issue #5: Replace the EXTRA_LIBSNAPPY_LDFLAGS setup with something
|
1825
|
+
slightly more standard, that also doesn't leak libtool command-line into
|
1826
|
+
configure.ac.
|
1827
|
+
|
1828
|
+
R=csilvers
|
1829
|
+
DELTA=7 (0 added, 4 deleted, 3 changed)
|
1830
|
+
|
1831
|
+
|
1832
|
+
Revision created by MOE tool push_codebase.
|
1833
|
+
MOE_MIGRATION=990
|
1834
|
+
|
1835
|
+
------------------------------------------------------------------------
|
1836
|
+
r7 | snappy.mirrorbot@gmail.com | 2011-03-23 12:12:22 +0100 (Wed, 23 Mar 2011) | 10 lines
|
1837
|
+
|
1838
|
+
|
1839
|
+
Fix public issue #4: Properly quote all macro arguments in configure.ac.
|
1840
|
+
|
1841
|
+
R=csilvers
|
1842
|
+
DELTA=16 (0 added, 0 deleted, 16 changed)
|
1843
|
+
|
1844
|
+
|
1845
|
+
Revision created by MOE tool push_codebase.
|
1846
|
+
MOE_MIGRATION=989
|
1847
|
+
|
1848
|
+
------------------------------------------------------------------------
|
1849
|
+
r6 | snappy.mirrorbot@gmail.com | 2011-03-23 12:11:54 +0100 (Wed, 23 Mar 2011) | 11 lines
|
1850
|
+
|
1851
|
+
|
1852
|
+
Fix public issue #7: Don't use internal variables named ac_*, as those belong
|
1853
|
+
to autoconf's namespace.
|
1854
|
+
|
1855
|
+
R=csilvers
|
1856
|
+
DELTA=6 (0 added, 0 deleted, 6 changed)
|
1857
|
+
|
1858
|
+
|
1859
|
+
Revision created by MOE tool push_codebase.
|
1860
|
+
MOE_MIGRATION=988
|
1861
|
+
|
1862
|
+
------------------------------------------------------------------------
|
1863
|
+
r5 | snappy.mirrorbot@gmail.com | 2011-03-23 12:11:09 +0100 (Wed, 23 Mar 2011) | 10 lines
|
1864
|
+
|
1865
|
+
|
1866
|
+
Add missing licensing headers to a few files. (Part 2/2.)
|
1867
|
+
|
1868
|
+
R=csilvers
|
1869
|
+
DELTA=12 (12 added, 0 deleted, 0 changed)
|
1870
|
+
|
1871
|
+
|
1872
|
+
Revision created by MOE tool push_codebase.
|
1873
|
+
MOE_MIGRATION=987
|
1874
|
+
|
1875
|
+
------------------------------------------------------------------------
|
1876
|
+
r4 | snappy.mirrorbot@gmail.com | 2011-03-23 12:10:39 +0100 (Wed, 23 Mar 2011) | 10 lines
|
1877
|
+
|
1878
|
+
|
1879
|
+
Add mising licensing headers to a few files. (Part 1/2.)
|
1880
|
+
|
1881
|
+
R=csilvers
|
1882
|
+
DELTA=24 (24 added, 0 deleted, 0 changed)
|
1883
|
+
|
1884
|
+
|
1885
|
+
Revision created by MOE tool push_codebase.
|
1886
|
+
MOE_MIGRATION=986
|
1887
|
+
|
1888
|
+
------------------------------------------------------------------------
|
1889
|
+
r3 | snappy.mirrorbot@gmail.com | 2011-03-23 12:10:04 +0100 (Wed, 23 Mar 2011) | 11 lines
|
1890
|
+
|
1891
|
+
|
1892
|
+
Use the correct license file for the Apache 2.0 license;
|
1893
|
+
spotted by Florian Weimer.
|
1894
|
+
|
1895
|
+
R=csilvers
|
1896
|
+
DELTA=202 (174 added, 0 deleted, 28 changed)
|
1897
|
+
|
1898
|
+
|
1899
|
+
Revision created by MOE tool push_codebase.
|
1900
|
+
MOE_MIGRATION=985
|
1901
|
+
|
1902
|
+
------------------------------------------------------------------------
|
1903
|
+
r2 | snappy.mirrorbot@gmail.com | 2011-03-18 18:14:15 +0100 (Fri, 18 Mar 2011) | 6 lines
|
1904
|
+
|
1905
|
+
|
1906
|
+
|
1907
|
+
|
1908
|
+
Revision created by MOE tool push_codebase.
|
1909
|
+
MOE_MIGRATION=
|
1910
|
+
|
1911
|
+
------------------------------------------------------------------------
|
1912
|
+
r1 | sesse@google.com | 2011-03-18 18:13:52 +0100 (Fri, 18 Mar 2011) | 2 lines
|
1913
|
+
|
1914
|
+
Create trunk directory.
|
1915
|
+
|
1916
|
+
------------------------------------------------------------------------
|