mirror of
https://github.com/xenia-project/snappy.git
synced 2025-02-18 10:17:39 +00:00
![snappy.mirrorbot@gmail.com](/assets/img/avatar_default.png)
in order to avoid having to do 32-to-64-bit signed conversions on a hot path during decompression. (Also fixes some MSVC warnings, mentioned in public issue 75, but more of those remain.) They cannot be size_t because we expect them to go negative and test for that. This saves a few movzwl instructions, yielding ~2% speedup in decompression. Sandy Bridge: Benchmark Base (ns) New (ns) Improvement ------------------------------------------------------------------------------------------------- BM_UFlat/0 48009 41283 2.3GB/s html +16.3% BM_UFlat/1 531274 513419 1.3GB/s urls +3.5% BM_UFlat/2 7378 7062 16.8GB/s jpg +4.5% BM_UFlat/3 92 92 2.0GB/s jpg_200 +0.0% BM_UFlat/4 15057 14974 5.9GB/s pdf +0.6% BM_UFlat/5 204323 193140 2.0GB/s html4 +5.8% BM_UFlat/6 13282 12611 1.8GB/s cp +5.3% BM_UFlat/7 6511 6504 1.6GB/s c +0.1% BM_UFlat/8 2014 2030 1.7GB/s lsp -0.8% BM_UFlat/9 775909 768336 1.3GB/s xls +1.0% BM_UFlat/10 182 184 1043.2MB/s xls_200 -1.1% BM_UFlat/11 167352 161630 901.2MB/s txt1 +3.5% BM_UFlat/12 147393 142246 842.8MB/s txt2 +3.6% BM_UFlat/13 449960 432853 944.4MB/s txt3 +4.0% BM_UFlat/14 620497 594845 775.9MB/s txt4 +4.3% BM_UFlat/15 265610 267356 1.8GB/s bin -0.7% BM_UFlat/16 206 205 932.7MB/s bin_200 +0.5% BM_UFlat/17 25561 24730 1.4GB/s sum +3.4% BM_UFlat/18 2620 2644 1.5GB/s man -0.9% BM_UFlat/19 45766 38589 2.9GB/s pb +18.6% BM_UFlat/20 171107 169832 1039.5MB/s gaviota +0.8% Sum of all benchmarks 3500103 3394565 +3.1% Westmere: Benchmark Base (ns) New (ns) Improvement ------------------------------------------------------------------------------------------------- BM_UFlat/0 72624 71526 1.3GB/s html +1.5% BM_UFlat/1 735821 722917 930.8MB/s urls +1.8% BM_UFlat/2 10450 10172 11.7GB/s jpg +2.7% BM_UFlat/3 117 117 1.6GB/s jpg_200 +0.0% BM_UFlat/4 29817 29648 3.0GB/s pdf +0.6% BM_UFlat/5 297126 293073 1.3GB/s html4 +1.4% BM_UFlat/6 28252 27994 842.0MB/s cp +0.9% BM_UFlat/7 12672 12391 862.1MB/s c +2.3% BM_UFlat/8 3507 3425 1040.9MB/s lsp +2.4% BM_UFlat/9 1004268 969395 1018.0MB/s xls +3.6% BM_UFlat/10 233 227 844.8MB/s xls_200 +2.6% BM_UFlat/11 230054 224981 647.8MB/s txt1 +2.3% BM_UFlat/12 201229 196447 610.5MB/s txt2 +2.4% BM_UFlat/13 609547 596761 685.3MB/s txt3 +2.1% BM_UFlat/14 824362 804821 573.8MB/s txt4 +2.4% BM_UFlat/15 371095 374899 1.3GB/s bin -1.0% BM_UFlat/16 267 267 717.8MB/s bin_200 +0.0% BM_UFlat/17 44623 43828 835.9MB/s sum +1.8% BM_UFlat/18 5077 4815 841.0MB/s man +5.4% BM_UFlat/19 74964 73210 1.5GB/s pb +2.4% BM_UFlat/20 237987 236745 746.0MB/s gaviota +0.5% Sum of all benchmarks 4794092 4697659 +2.1% Istanbul: Benchmark Base (ns) New (ns) Improvement ------------------------------------------------------------------------------------------------- BM_UFlat/0 98614 96376 1020.4MB/s html +2.3% BM_UFlat/1 963740 953241 707.2MB/s urls +1.1% BM_UFlat/2 25042 24769 4.8GB/s jpg +1.1% BM_UFlat/3 180 180 1065.6MB/s jpg_200 +0.0% BM_UFlat/4 45942 45403 1.9GB/s pdf +1.2% BM_UFlat/5 400135 390226 1008.2MB/s html4 +2.5% BM_UFlat/6 37768 37392 631.9MB/s cp +1.0% BM_UFlat/7 18585 18200 588.2MB/s c +2.1% BM_UFlat/8 5751 5690 627.7MB/s lsp +1.1% BM_UFlat/9 1543154 1542209 641.4MB/s xls +0.1% BM_UFlat/10 381 388 494.6MB/s xls_200 -1.8% BM_UFlat/11 339715 331973 440.1MB/s txt1 +2.3% BM_UFlat/12 294807 289418 415.4MB/s txt2 +1.9% BM_UFlat/13 906160 884094 463.3MB/s txt3 +2.5% BM_UFlat/14 1224221 1198435 386.1MB/s txt4 +2.2% BM_UFlat/15 516277 502923 979.5MB/s bin +2.7% BM_UFlat/16 405 402 477.2MB/s bin_200 +0.7% BM_UFlat/17 61640 60621 605.6MB/s sum +1.7% BM_UFlat/18 7326 7383 549.5MB/s man -0.8% BM_UFlat/19 94720 92653 1.2GB/s pb +2.2% BM_UFlat/20 360435 346687 510.6MB/s gaviota +4.0% Sum of all benchmarks 6944998 6828663 +1.7% git-svn-id: https://snappy.googlecode.com/svn/trunk@77 03e5f5b5-db94-4691-08a0-1a8bf15f6143
Snappy, a fast compressor/decompressor. Introduction ============ Snappy is a compression/decompression library. It does not aim for maximum compression, or compatibility with any other compression library; instead, it aims for very high speeds and reasonable compression. For instance, compared to the fastest mode of zlib, Snappy is an order of magnitude faster for most inputs, but the resulting compressed files are anywhere from 20% to 100% bigger. (For more information, see "Performance", below.) Snappy has the following properties: * Fast: Compression speeds at 250 MB/sec and beyond, with no assembler code. See "Performance" below. * Stable: Over the last few years, Snappy has compressed and decompressed petabytes of data in Google's production environment. The Snappy bitstream format is stable and will not change between versions. * Robust: The Snappy decompressor is designed not to crash in the face of corrupted or malicious input. * Free and open source software: Snappy is licensed under a BSD-type license. For more information, see the included COPYING file. Snappy has previously been called "Zippy" in some Google presentations and the like. Performance =========== Snappy is intended to be fast. On a single core of a Core i7 processor in 64-bit mode, it compresses at about 250 MB/sec or more and decompresses at about 500 MB/sec or more. (These numbers are for the slowest inputs in our benchmark suite; others are much faster.) In our tests, Snappy usually is faster than algorithms in the same class (e.g. LZO, LZF, FastLZ, QuickLZ, etc.) while achieving comparable compression ratios. Typical compression ratios (based on the benchmark suite) are about 1.5-1.7x for plain text, about 2-4x for HTML, and of course 1.0x for JPEGs, PNGs and other already-compressed data. Similar numbers for zlib in its fastest mode are 2.6-2.8x, 3-7x and 1.0x, respectively. More sophisticated algorithms are capable of achieving yet higher compression rates, although usually at the expense of speed. Of course, compression ratio will vary significantly with the input. Although Snappy should be fairly portable, it is primarily optimized for 64-bit x86-compatible processors, and may run slower in other environments. In particular: - Snappy uses 64-bit operations in several places to process more data at once than would otherwise be possible. - Snappy assumes unaligned 32- and 64-bit loads and stores are cheap. On some platforms, these must be emulated with single-byte loads and stores, which is much slower. - Snappy assumes little-endian throughout, and needs to byte-swap data in several places if running on a big-endian platform. Experience has shown that even heavily tuned code can be improved. Performance optimizations, whether for 64-bit x86 or other platforms, are of course most welcome; see "Contact", below. Usage ===== Note that Snappy, both the implementation and the main interface, is written in C++. However, several third-party bindings to other languages are available; see the Google Code page at http://code.google.com/p/snappy/ for more information. Also, if you want to use Snappy from C code, you can use the included C bindings in snappy-c.h. To use Snappy from your own C++ program, include the file "snappy.h" from your calling file, and link against the compiled library. There are many ways to call Snappy, but the simplest possible is snappy::Compress(input.data(), input.size(), &output); and similarly snappy::Uncompress(input.data(), input.size(), &output); where "input" and "output" are both instances of std::string. There are other interfaces that are more flexible in various ways, including support for custom (non-array) input sources. See the header file for more information. Tests and benchmarks ==================== When you compile Snappy, snappy_unittest is compiled in addition to the library itself. You do not need it to use the compressor from your own library, but it contains several useful components for Snappy development. First of all, it contains unit tests, verifying correctness on your machine in various scenarios. If you want to change or optimize Snappy, please run the tests to verify you have not broken anything. Note that if you have the Google Test library installed, unit test behavior (especially failures) will be significantly more user-friendly. You can find Google Test at http://code.google.com/p/googletest/ You probably also want the gflags library for handling of command-line flags; you can find it at http://code.google.com/p/google-gflags/ In addition to the unit tests, snappy contains microbenchmarks used to tune compression and decompression performance. These are automatically run before the unit tests, but you can disable them using the flag --run_microbenchmarks=false if you have gflags installed (otherwise you will need to edit the source). Finally, snappy can benchmark Snappy against a few other compression libraries (zlib, LZO, LZF, FastLZ and QuickLZ), if they were detected at configure time. To benchmark using a given file, give the compression algorithm you want to test Snappy against (e.g. --zlib) and then a list of one or more file names on the command line. The testdata/ directory contains the files used by the microbenchmark, which should provide a reasonably balanced starting point for benchmarking. (Note that baddata[1-3].snappy are not intended as benchmarks; they are used to verify correctness in the presence of corrupted data in the unit test.) Contact ======= Snappy is distributed through Google Code. For the latest version, a bug tracker, and other information, see http://code.google.com/p/snappy/
Description
Languages
C++
93.1%
M4
3.5%
C
2.7%
Makefile
0.6%