Skip to content

Commit

Permalink
1.1.4 release.
Browse files Browse the repository at this point in the history
  • Loading branch information
Alkis Evlogimenos committed Jan 27, 2017
1 parent 8bfb028 commit 2d99bd1
Show file tree
Hide file tree
Showing 2 changed files with 10 additions and 2 deletions.
8 changes: 8 additions & 0 deletions NEWS
Original file line number Diff line number Diff line change
@@ -1,3 +1,11 @@
Snappy v1.1.4, January 25th 2017:

* Fix a 1% performance regression when snappy is used in PIE executables.

* Improve compression performance by 5%.

* Improve decompression performance by 20%.

Snappy v1.1.3, July 6th 2015:

This is the first release to be done from GitHub, which means that
Expand Down
4 changes: 2 additions & 2 deletions configure.ac
Original file line number Diff line number Diff line change
@@ -1,11 +1,11 @@
m4_define([snappy_major], [1])
m4_define([snappy_minor], [1])
m4_define([snappy_patchlevel], [3])
m4_define([snappy_patchlevel], [4])

# Libtool shared library interface versions (current:revision:age)
# Update this value for every release! (A:B:C will map to foo.so.(A-C).C.B)
# http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
m4_define([snappy_ltversion], [4:0:3])
m4_define([snappy_ltversion], [4:1:3])

AC_INIT([snappy], [snappy_major.snappy_minor.snappy_patchlevel])
AC_CONFIG_MACRO_DIR([m4])
Expand Down

2 comments on commit 2d99bd1

@dyu
Copy link

@dyu dyu commented on 2d99bd1 Feb 28, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/google/snappy/releases/download/1.1.4/snappy-1.1.4.tar.gz has different contents to the actual source archive.
Care to explain why that is?
I posted this here since the project has the issue tab disabled.

39d38
< #include <limits>
320,323c319,331
<   if (input_size > kMaxHashTableSize) {
<     *table_size = kMaxHashTableSize;
<   } else if (input_size < 256) {
<     *table_size = 256;
---
>   // Use smaller hash table when input.size() is smaller, since we
>   // fill the table, incurring O(hash table size) overhead for
>   // compression, and if the input is short, we won't need that
>   // many hash table entries anyway.
>   assert(kMaxHashTableSize >= 256);
>   size_t htsize = 256;
>   while (htsize < kMaxHashTableSize && htsize < input_size) {
>     htsize <<= 1;
>   }
> 
>   uint16* table;
>   if (htsize <= ARRAYSIZE(small_table_)) {
>     table = small_table_;
325,335c333,341
<     // Since table size must be a power of 2, round up to the next power of 2.
<     *table_size = 1 << (std::numeric_limits<size_t>::digits -
<                         __builtin_clzll(input_size - 1));
<   }
<   if (*table_size <= ARRAYSIZE(small_table_)) {
<     memset(small_table_, 0, 2 * *table_size);
<     return small_table_;
<   }
<   if (!large_table_) large_table_ = new uint16[kMaxHashTableSize];
<   memset(large_table_, 0, 2 * *table_size);
<   return large_table_;
---
>     if (large_table_ == NULL) {
>       large_table_ = new uint16[kMaxHashTableSize];
>     }
>     table = large_table_;
>   }
> 
>   *table_size = htsize;
>   memset(table, 0, htsize * sizeof(*table));
>   return table;

@alkis
Copy link
Contributor

@alkis alkis commented on 2d99bd1 Feb 28, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like a problem with the release process. There is going to be a new release soon.

Please sign in to comment.