Re: Header Table and Static Table Indicies Switched

> Is that 8% relative to just the second request?

It is the relative difference in the size of the second request after
compression.

That is if using the static table first the request compressed to 100
bytes and with the header table first it compressed to 92 bytes then
it is 8% smaller.

>
> The percentages I have been reporting have been relative to to the entire
> data stream of all requests, so if comparing your 8% to the numbers I've
> quoted, then it should be much less < 8%.     I'm not saying that is not a
> valid way to report compression, I'm just making sure we don't compare
> apples with oranges.
>
> Also, I don't doubt that there are usage patterns for each index ordering
> will be better or worse.  The question is, are such examples widely
> representative?      We are never going to find a perfect compression that
> is one-size fits all and whilst we are looking at compression savings of
> 60-70%, I think that any variation that is +/- <8% for particular data sets
> is pretty much down among the noise!

The order of the tables has no impact on the difficulty of
implementation, it's basically a swap of the length checks and which
table you offset. Why would we give up 8% in compression for free?

Received on Sunday, 3 August 2014 01:55:35 UTC