一些常用到的库记录

1.  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. On a single core of a Core i7 processor in 64-bit mode, Snappy compresses at about 250 MB/sec or more and decompresses at about 500 MB/sec or more.

Snappy is widely used inside Google, in everything from BigTable and MapReduce to our internal RPC systems. (Snappy has previously been referred to as “Zippy” in some presentations and the likes.)

For more information, please see the README. Benchmarks against a few other compression libraries (zlib, LZO, LZF, FastLZ, and QuickLZ) are included in the source code distribution. The source code also contains a formal format specification, as well as a specification for a framing format useful for higher-level framing and encapsulation of Snappy data, e.g. for transporting Snappy-compressed data across HTTP in a streaming fashion. Note that the Snappy distribution currently has no code implementing the latter, but some of the ports do (see below).

Snappy is written in C++, but C bindings are included, and several bindings to other languages are maintained by third parties:

2.  The primary goal of this project is to define a portable and efficientC programming interface (API) to determine the call-chain of aprogram. The API additionally provides the means to manipulate thepreserved (callee-saved) state of each call-frame and to resumeexecution at any point in the call-chain (non-local goto). The APIsupports both local (same-process) and remote (across-process)operation. As such, the API is useful in a number ofapplications. Some examples include:

exception handling

The libunwind API makes it trivial to implement thestack-manipulation aspects of exception handling.

debuggers

The libunwind API makes it trivial for debuggers to generate thecall-chain (backtrace) of the threads in a running program.

introspection

It is often useful for a running thread to determine its call-chain. For example, this is useful to display error messages (to show how the error came about) and for performance monitoring/analysis.

efficient setjmp()

With libunwind, it is possible to implement an extremelyefficient version of setjmp(). Effectively, the only context thatneeds to be saved consists of the stack-pointer(s).