Lines Matching full:that
16 size (except that the compressed data for one block must fit in
17 available memory). A block is terminated when deflate() determines that
30 hash chains, the algorithm simply discards matches that are too old.
63 that you can decode fast. The most important characteristic is that shorter
67 inflate() sets up a first level table that covers some number of bits of
68 input less than the length of longest code. It gets that many bits from the
70 code is that many bits or less and how many, and if it is, it will tell
81 to set that variable for the maximum speed.
85 values, and the size of the first table is six bits. Note that for each of
95 looks like. You are correct that it's not a Huffman tree. It is simply a
98 symbol is shorter than nine bits, then that symbol's translation is duplicated
99 in all those entries that start with that symbol's bits. For example, if the
103 If the symbol is longer than nine bits, then that entry in the table points
105 entries as needed. The idea is that most of the time the symbol will be short
106 and there will only be one table look up. (That's whole idea behind data
118 longest symbol is? The reason is that if you do that, you end up spending
120 At least for deflate's output that generates new trees every several 10's of
121 kbytes. You can imagine that filling in a 2^15 entry table for a 15-bit code
124 that's essentially a Huffman tree. But then you spend two much time
157 Each entry is what the bits decode as and how many bits that is, i.e. how
181 So what we have here are three tables with a total of 20 entries that had to
182 be constructed. That's compared to 64 entries for a single table. Or
184 entry table). Assuming that the code ideally represents the probability of
185 the symbols, it takes on the average 1.25 lookups per symbol. That's compared
189 There, I think that gives you a picture of what's going on. For inflate, the
192 indicates a base value and a number of bits to fetch after the code that is
194 data structures created in inftrees.c try to encode all that information
225 size (except that the compressed data for one block must fit in
226 available memory). A block is terminated when deflate() determines that
239 hash chains, the algorithm simply discards matches that are too old.
272 that you can decode fast. The most important characteristic is that shorter
276 inflate() sets up a first level table that covers some number of bits of
277 input less than the length of longest code. It gets that many bits from the
279 code is that many bits or less and how many, and if it is, it will tell
290 to set that variable for the maximum speed.
294 values, and the size of the first table is six bits. Note that for each of
304 looks like. You are correct that it's not a Huffman tree. It is simply a
307 symbol is shorter than nine bits, then that symbol's translation is duplicated
308 in all those entries that start with that symbol's bits. For example, if the
312 If the symbol is longer than nine bits, then that entry in the table points
314 entries as needed. The idea is that most of the time the symbol will be short
315 and there will only be one table look up. (That's whole idea behind data
327 longest symbol is? The reason is that if you do that, you end up spending
329 At least for deflate's output that generates new trees every several 10's of
330 kbytes. You can imagine that filling in a 2^15 entry table for a 15-bit code
333 that's essentially a Huffman tree. But then you spend two much time
366 Each entry is what the bits decode as and how many bits that is, i.e. how
390 So what we have here are three tables with a total of 20 entries that had to
391 be constructed. That's compared to 64 entries for a single table. Or
393 entry table). Assuming that the code ideally represents the probability of
394 the symbols, it takes on the average 1.25 lookups per symbol. That's compared
398 There, I think that gives you a picture of what's going on. For inflate, the
401 indicates a base value and a number of bits to fetch after the code that is
403 data structures created in inftrees.c try to encode all that information
434 size (except that the compressed data for one block must fit in
435 available memory). A block is terminated when deflate() determines that
448 hash chains, the algorithm simply discards matches that are too old.
481 that you can decode fast. The most important characteristic is that shorter
485 inflate() sets up a first level table that covers some number of bits of
486 input less than the length of longest code. It gets that many bits from the
488 code is that many bits or less and how many, and if it is, it will tell
499 to set that variable for the maximum speed.
503 values, and the size of the first table is six bits. Note that for each of
513 looks like. You are correct that it's not a Huffman tree. It is simply a
516 symbol is shorter than nine bits, then that symbol's translation is duplicated
517 in all those entries that start with that symbol's bits. For example, if the
521 If the symbol is longer than nine bits, then that entry in the table points
523 entries as needed. The idea is that most of the time the symbol will be short
524 and there will only be one table look up. (That's whole idea behind data
536 longest symbol is? The reason is that if you do that, you end up spending
538 At least for deflate's output that generates new trees every several 10's of
539 kbytes. You can imagine that filling in a 2^15 entry table for a 15-bit code
542 that's essentially a Huffman tree. But then you spend two much time
575 Each entry is what the bits decode as and how many bits that is, i.e. how
599 So what we have here are three tables with a total of 20 entries that had to
600 be constructed. That's compared to 64 entries for a single table. Or
602 entry table). Assuming that the code ideally represents the probability of
603 the symbols, it takes on the average 1.25 lookups per symbol. That's compared
607 There, I think that gives you a picture of what's going on. For inflate, the
610 indicates a base value and a number of bits to fetch after the code that is
612 data structures created in inftrees.c try to encode all that information