/tmp/buildd/xz-utils-5.0.0/src/liblzma/rangecoder/range_common.h File Reference

Common things for range encoder and decoder. More...

Defines
#define	RC_SHIFT_BITS   8
#define	RC_TOP_BITS   24
#define	RC_TOP_VALUE   (UINT32_C(1) << RC_TOP_BITS)
#define	RC_BIT_MODEL_TOTAL_BITS   11
#define	RC_BIT_MODEL_TOTAL   (UINT32_C(1) << RC_BIT_MODEL_TOTAL_BITS)
#define	RC_MOVE_BITS   5
#define	bit_reset(prob)   prob = RC_BIT_MODEL_TOTAL >> 1
#define	bittree_reset(probs, bit_levels)
Typedefs
typedef uint16_t	probability
	Type of probabilities used with range coder.

---

Detailed Description

Common things for range encoder and decoder.

---

Define Documentation

#define bittree_reset	(		probs,
			bit_levels
	)

Value:

for (uint32_t bt_i = 0; bt_i < (1 << (bit_levels)); ++bt_i) \
                bit_reset((probs)[bt_i])

---

Typedef Documentation

typedef uint16_t probability

Type of probabilities used with range coder.

This needs to be at least 12-bit integer, so uint16_t is a logical choice. However, on some architecture and compiler combinations, a bigger type may give better speed, because the probability variables are accessed a lot. On the other hand, bigger probability type increases cache footprint, since there are 2 to 14 thousand probability variables in LZMA (assuming the limit of lc + lp <= 4; with lc + lp <= 12 there would be about 1.5 million variables).

With malicious files, the initialization speed of the LZMA decoder can become important. In that case, smaller probability variables mean that there is less bytes to write to RAM, which makes initialization faster. With big probability type, the initialization can become so slow that it can be a problem e.g. for email servers doing virus scanning.

I will be sticking to uint16_t unless some specific architectures are *much* faster (20-50 %) with uint32_t.